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