Globally unique Id's for primary keys

[Yair Sageev]

We plan to have a number of field personnel use Access and then use XML to
sync their data with our central office Access database. The problem is
that each agent might end up using the same autonumber for the primary key
Id of a record. We would like to have access automatically assign a
"globally unique" Id, similar to what COM components use to differentiate
themselves. Is their an easy way to do this?

Thanks in advance.

 

[Roger Carlson]

The best Access has is to set the autonumber field to Random in the
properties, rather than Increment.

 

[Yair Sageev]

Thanks. But the random thing won't cut it. I noticed in the field
properties you can set the number to "Replication ID". What exactly is
this?

 

[Douglas J. Steele]

Take a look at what Michka has to say about using GUIDs as PKs at
http://www.trigeminal.com/usenet/usenet011.asp

 

[Yair Sageev]

Thanks. I do need uniqueness though. Some questions about what Michka
writes:

"1) In an app, a "ReplicationID Autonumber field" (i.e. an autonumber GUID),
which is then turned into a replica, Jet will use your column instead of
creating an s_Guid column. Unfortunately, the Conflict Resolver Wizard of
Access 95 and 97 and the Conflict Viewer of Access 2000 are assuming an
s_Guid column and thus conflict resolution will not work properly via the
wizard, and you are on your own. "

Is this problem resolved in Access 2002 and later?

"2) A GUID is literally stored as a 16-byte binary value. It also has a
canonical (text) form and a DAO/Jet-specific form as well, consisting of
{guid {xxx}} where xxx is the "canonical" value. This last format is what
Jet will display anytime you do a select statement from a GUID field through
DAO.."

If you're not displaying the PK to users the problems in #2 shouldn't be
problems, right? Can you still run queries and synchronize with GUID's?

 

[Douglas J. Steele]

I don't believe 1 has been changed.

And I don't see what not displaying the PK to the users has to do with point
2. You're still going to need to refer to the PK even if you don't show it
to the user (having it as a hidden field, for example).