- - - -I hope you and Kevin won't mind my interjecting a couple of points here.

No! Jump in!

- - - -1) What you are asking for does not sound that difficult and is one way (not the best) to address your specific situation. However what you are asking for is not a true global ID, of the type that SQL Server (and every other client server database ) generates. A true GUID is truly unique not accross the database, but accoss multiple databases. In fact if working perfectly (and of course nothing works perfectly) -- a GUID is unique across the entire planet. - - - - -

I agree with your definition of GUID.


- - - - -2) Secondly, In my opinion, the best way to handle your specific situation is to add one flag to the address table, address type. 1=contactid, 2=employid and so on. Then based on these values you would know which table to lookup the ID in. With GUIDS you still have to search all the tables to find out which table it is in, so this would give you better performance, while remaining pretty simple. - - - - -

Hmmm. Interesting. I've actually thought of a variant like this before, but was concerned about it breaking some day, if a table name got changed, etc. Also, if I went with 1=contactid, 2=employee, then we'd have to keep maintaining that list, by adding more types, for each table referencing address.

I do have a question though. Your answer made it seem like I'd have to look inside each table that ever referenced the Address table. This relationship seems backwards to at least how I was looking at it.

Here is what I was pictured:
1. I open our Customer program, and first see a form with a grid, showing all our customers.

2. I choose what customer I want to work on, by double-clicking on that record in the grid. This pops up Customer-Edit form

3. Looking at the customer edit form, I see everything about them. Contacts, products they own, links to invoices, phone numbers, and addresses. (shipping, billing, etc)

4. So, I know this company's ID. (#403011) Otherwise I wouldn't be looking at their form. All I'd have to do to show all their addresses is to use a view that shows all addresses where AddressTable.CustomerID = 403011
(But then only Customer could use Address Table.

5. If I used parts of your idea, maybe I could use the view that showed all addresses that have AddressTable.CustomerID = 403011 and AddressTable.cTableName = 'Customer'
Is that what you were thinking? I just might do it, although I'm still concerned about the table name changing?

6. Now... if my CustomerID was Globally unique (atleast in our development) then I could just show all addresses that have AddressTable.OwnerID = 403011 and I wouldn't have to worry about Employee Table having an ID = 403011 too. All tables could use the Address table.