>I would suggest the GUID too. However, most of these distributed type applications require a field for location...and that's a one time setup.
>
>


Also, performance can also be an issue. In theory, I love the idea of GUIDs, and about two years ago I started using them a lot... well, guess what? They are bulky and slow down SELECTs, and the code to generate them is a touch slow compared to similar key generation code I have used...

If I had it to do over again, I would have assigned a unique 2 or 3 byte location code, and then created a primary key that was the location code + a unique ID. While this duplicates some info (the location code), it gives you a primary key that's not a compound key, and most likely, it will be smaller and quicker than a GUID.




>>>
>>>1) Use a compound PK with two fields, location and recordID
>>
>>That makes it a compound key!
>>
>>>2) Use a GUID.
>>
>>This is what I would suggest. It does not require compound primary keys and no maintenance if more location get added
>>
>>
>>
>>I believe there is a API call to get the GUID
>>
>>Peter