>Pertti,
>
>>True, since SYS(2015) is derived from the workstation clock, and workstations on networks are never completely synchronized. It is a pretty sure-fire unique value on one single system, though -- running SYS(2015) in a tight loop on my 3.4 Pentium with 2GB memory did not produce any duplicates during 1000 iterations, though. But a GUID would give you a truly unique ID, every time.
>
>Actually, I tried doing the same with 10 workstations simultaneously appending a central table with their SYS(2015) generated values. So far, no duplicates arose. I really just wanted to be sure.
>
>>The LastPKID() -strategy has a few important benefits, however: While it is a bit more (setup) work than simply getting a GUI, with this approach you can create integer keys, which take a whole lot less space than GUI and are a whole lot faster to search (in a huge data table).
>
>To be safe, I guess I will just to my GetLastNumber() stuff. I was hoping to use SYS(2015) instead to cut off another layer of 'fat'.
>
>>I don't personally completely trust the autoincrement -field property in VFP -- it has problems specifically if you use views or stored procedures. Also, since the current autoinc value is stored in the table header, it is at risk during crashes.
>
>Me neither.
>
>Thanks!
>Dennis

Dennis,
I had a very simple demonstration code showing you can easily duplicate with 2 stations:) Believe me you can even duplicate doing that manually (programmatically easier to insert faster) sitting 2 persons on same table and inserting with say Ctrl+Y (where default is sys(2015)).
GetLastNumber is returning integer I think. So I'd repeat, use GUID. Or start with integer, when you start to have headaches, revert to using GUID:)
Cetin