I've run into a situation where I miss my SQL days: GUIDS'. Right now in Mere Mortals, we can use NewID() stored procedure to get a unique identifier --for that table--.

I've taken a look at the NEWID code, and have a few questions. Why does the ID table keep track of each table's "next" id to use? Why not just use the same concept, but keep track of just one ID. So if any table is making a new record, instead of looking up the ID for it's table, just look up the new ID for all tables...
Had this been tried before? Did Kevin run into a problem with conflicts of some kind?

The reason I was looking at all this is because (for example) I have an Address table. I'd like to put all addresses of all our projects in this table. However, I have a lot of objects/tables that need addresses. (Customers, Employees, Contacts, etc.) In the Address Table, I can't reference iOwnerID = 1 to belong to AddressID #1, because each table (Customer, employees, contacts) will have their own ID=1.
I also can't add fields to the Address Table such as: "CustomerID", "EmployeeID", "ContactID" because the list could go on forever. At the moment I'm using reference tables, but that causes headaches for something as simple as referencing addresses.

Thanks,
Dustin
Keystone