>>Based on your last message, how do you define your primary keys if you do not use compound indexes?
>>
>>Jason
>
>All of my tables (without exception) have an integer that is used as the primary key - this is not unique across tables, but it would not take a great deal of effort to make it so. If new data is created at multiple (disconnected) locations, then I would use a GUID.

I was thinking - for disconnected locations, wouldn't it be more convenient, rather than using a GUID, to use something like bintoc(LocationId, 2) + bintoc(SerialNumber(...)), where LocationId is a unique number assigned to each disconnected location, and SerialNumber() is the same function you currently use to get an "auto-incremental" number for individual locations?

This would use only 6 bytes, instead of 16, and you would still use only a single field. But this is something I didn't try out yet.

>
>I prefer Integers, because if I need to delete a record, I just multiply the (normally) positive integer by -1 and make it negative. When I need to add a new record I first Select Top 1 iPrimaryKey From Table Where iPrimaryKey < 0 - if there are no rows returned, then I need to really create a new record and not reuse an old record. Reused records, simply have there primary key multiplied by -1 again, to return it to its original positive value.

That looks like a very efficient way to re-use records. I will have to remember it.

But note that you may still need indices on combined fields, to ensure uniqueness on what looks, to the end-user, as a primary key on more than one field.