>>For example, if the workstations should periodically synchronize their clock >with the server, or some external reference (sometimes necessary) then their >clock can go backwards then the possibility of creating a duplicate key is not >zero and will be proportional to the adjusted time (for example if the adjust >was only .1 second the collision will be less probable than a 10 minute >adjustment).
>
>I over-simplified in my explanation. CoCreateGuid uses the following to create the GUID:
>
>1. NIC address. This assures that the GUID is globally unique.

It synthesizes a MAC address if none is available; THis is one source of the incredibly unlikely but still possible to get a duplicate assignment - the chance of getting a repeat are so small that it would not make sense to check for dups at generation, leaving it to an error handler to correct if it occurred. And if it did, I'd be sure to play the lottery that night, too.

>2. System clock time. This assures that the GUID is unique to the local machine, as well as globally unique given #1.

Source 2 of duplicates; danger shows up when the system clock gets reset to an earlier date/time.

>3. A pair of persistent counters that will account for system clock scenarios as you mention above. This assures that the GUID is unique, even if you reset the system clock, or if the OS resets it for Daylight Savings Time (for instance).


I believe the effective chance of duplicating a GUID is vanishingly small, on the order of 1/2^100 or greater; you can also tell the underlying API call to use a different API call, UuidCreateSequential(), which while guarenteed only to be unique to a given system is always unique for that system, so if we get all our UUIDs from a single source (SET SARCASM ONgee, too bad VFP doesn't have a remote server capabilitySET SARCASM OFF - classic case for DCOM!) then UuidCreateSequential() removes remote chances for duplication.