>Hello, Javier, and thanks for the reply.
>
>>if you are afraid of getting the same sys(2015) for calling it inside the millisecond,
>>simply add a few lines tou your uniqueID() function to skip this chance:
>>
>>

>>	lcUniqueID = sys(2015)
>>	do while lcUniqueID == sys(2015)
>>	endDo
>>
>>	return lcUniqueID
>>
>>

>
>Aha. Nice touch, and we are "kind of" worried about it, especially
>when merging multiple VFP databases into one MySQL database. Unfortunately,
>most of the client apps won't have access to the net, so they'll have
>to generate their unique keys all by their lonesome. OTOH, this can
>also be fortuitous, especially when you consider the fact that not
>all system clocks are the same and synchronous. The problem arises
>when both clients are synced to the same system clock, usually located
>on a shared server, of course. Off the top of my head (and not doing
>research on this topic too deeply), I'd say the chances of having
>a unique ID collision is somewhere between slim and very slim,
>although I've heard that it has happend. Looking at the code that
>Sergey pointed out, however, leads me to believe that it doesn't
>happen very often. As matter of fact, I'd be willing to bet that
>when the IDs hash to the same bucket, multiple databases were being
>merged into a single database, and the act of doing this was the
>culprit. That, and some "not too fantastic" coding on someones behalf.
>(Read: lazyness! :^)
>
>>it won't add a noticiable delay when generating thousands of IDs and it's safer.
>
>Great. I'll make sure that I add it to my VFP code.
>
>Regards,
>
>Randall

Randall,
Read my reply, This piece is not needed.
OTOH sys(2015) duplication is not very slim (or even slim) in a multiuser environment. Even only 2 fast typist were able to produce it (given that you might have in code insert/imports computers surely increase that level to almost over 50%).
Read this sys(2015) alone is never safe. Use GUID.
Cetin