1. A GUID is probably generated faster than incrementing the last number used stored in some table... since it is a windows API function.

2. GUIDs can be generated client side or server side which is nice.

3. You should also be able to use the NewID function as a default for your keys which basically gives you the same funcationality as identity fields.

4. The main problem is that they are not very 'human' friendly. You can look at a result set and see that all the 100s are for a certain customer, or whaterver.

BOb


>>I use surrogate primary keys in VFP also. Identity column are just an easy way to auto number the next row inserted. But they do present a few problems as does just about any way that you try to id the next row.
>>
>>The old standby method of keeping a table of next ids has its problems also, i.e., you get the last number, add one to it, just as someone inserts a row and a new number before I save mine.
>>
>>The difficult part of identity columns, and I haven't come up with a satisfactory method, is when their used as foreign keys and they must be updated at the same time as the parent. As in invoice header and invoice details. You would want to handle it all in a transaction, updating the invoice header then the details.
>>
>>Maybe Michael Levy can give us an elegant way.
>
>I had a reply in the VFP Forum from Trey Walpole who suggested using GUIDs - Globally Unique Identifiers. I have read they are good for distributed and replicated data. He gave me a link to a MS page some code to generate GUIDs with VFP. This seems like a good idea, but I am concerned about performance:
>
>1. Time to generate a GUID
>2. GUID are 16 bytes, I believe