Hi Walter,

Several reasons. The biggest reason is that VFP monolithic apps don't use a server database and with Windows internal buffering and whatnot, duplicate keys are quite possible, especially on peer-to-peer small LANs and/or in heavy traffic.

Since I use surrogate keys, I don't care if the PK doesn't actually mean anything and I know that the GUID will be unique no matter where it is generated.

With server databases, I use identity fields, uniqueidentifiers, or (Oracle) sequences. There I am not as picky because I know that the database server will manage that quite well without fear of >kaboom<



>Thanks, This is one to remember.
>
>Just one more question. Why don't you use the common approach of using a pk table ? IOW what advantaged does it have ?
>
>>As a character field. I think I got this code from Rick Strahl's website a few years ago....

>>
>>*** Run this once at the beginning of your app (in your MAIN.PRG) to declare the calls.
>>
>>DECLARE INTEGER CoCreateGuid ;
>>  IN Ole32.dll ;
>>  STRING @lcGUIDStruc
>>DECLARE INTEGER StringFromGUID2 ;
>>  IN Ole32.dll ;
>>  STRING cGUIDStruc, ;
>>  STRING @cGUID, ;
>>  LONG nSize
>>
>>*** Run this as required to get a unique key.
>>
>>PROCEDURE GetGUID
>>cStrucGUID=SPACE(16)
>>cGUID=SPACE(80)
>>nSize=40
>>IF CoCreateGuid(@cStrucGUID) # 0
>>   RETURN ""
>>ENDIF
>>IF StringFromGUID2(cStrucGUID,@cGuid,nSize) = 0
>>  RETURN ""
>>ENDIF
>>RETURN STRCONV(LEFT(cGUID,76),6)
>>ENDPROC

>>
>>
>>>>I have to go back to an earlier point in another (or the same?) thread:
>>>
>>>>Surrogate keys are the absolute best way to guarantee a unique primary key bar none. Period. And, IMHO, the CoCreateGUID API call absolutely guarantees uniqueness spanning not only the table, but the database, the machine, the network, the freaking world.
>>>
>>>On second thought. You raise an interesting point up here. Unlike many others you do not choose for a separate PK table up here. If I may ask, what are your motivations. How do you store it in the table (data type) ?
>>>
>>>Walter,