Dorin,
pmfji, but you can reduce the size of the guid key to 16 bytes (see CoCreateGuid() )
The only things to watch for are (1) the field has to be a char binary (NOCPTRANS) and (2) the collating sequence must be MACHINE
______________________
>You can think also to sys(2015)+WorkstationId as a character type PK solution. Only WorkstationId must be an unique value, saved in registry or local config files. GUIDs are very random generated values and I think that there is an overhead to mantain indexes (also think about one-to-many relationships).
>
>I've done some tests, maybe results can be useful:
>
>With 100000 records, only one PK fields, 38 bytes GUID type as in sample...
>
http://support.microsoft.com/support/kb/articles/Q269/3/87.asp>and right(SYS(2015),9) + 3 chars workstation id (12 in total)
>
>
>Index size GUID : 6.786.548 bytes
>Index size SYS(2015)+WsId : 863.744 bytes
>
>7.85 times more for GUID index
>
>After a REINDEX command
>Index size GUID : 4.767.744 bytes
>Index size SYS(2015)+WsId : 850.432 bytes
>
>5.60 times more for GUID indexes
>
>Average seek times , 100000 iterations, random keys
>Index on GUID : 1.880 seconds
>The other index : 0.954 seconds
>
>
>
>>>Hi,
>>>I am designing database for my new application. I think to use AutoNumber as PK, however, it will cause problem while replication. Do you think combination of AutoNumber and BrandID as PK is a good solution? Will it complicated coding? how about GUID?
>>>
>>>Thank you
>>
>>As Sylvain said already,
>>Go with GUID.
>>
>>For a long discussion and sample on it check :
>>
>>
http://oldlook.experts-exchange.com/Databases/FoxPro/Q_20764442.html>>
>>Cetin
Gregory