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