=?Utf-8?B?SmVycnkgV2hpdHRsZQ==?=
Unless you are using replication, you don't need the replicationID
data type.
You don't need it even if you're using Replication.
Many would think that a random long integer would be dangerous if
you're adding lots of records in lots of replicas. But you run the
risk of creating duplicates randomly only if you're not synching
regularly. That is, the random long integer is not truly random --
it's only random chosen from the pool of values that have not yet
been used.
In two independent MDBs, the used-up pools will be different and
thus could result in duplicates fairly easily.
But in replicas from a single replica set, after a synch, any two
replicas will have exactly the same used-up pool of randomly
generated values. Thus, the chances for a collision are very small
as long as the replicas synch relatively frequently (where
"frequently" will determined by the rate at which new records are
being added -- the more that are added in a single day, the sooner
you need to synch with the replica set).
Doug Steele already cited Michael Kaplan's article on the problems
that come with using GUIDs in Access:
http://www.trigeminal.com/usenet/usenet011.asp
It causes more problems in replicated databases than in
non-replicated, since it breaks the built-in conflict resolver and
you then end up have to write your own conflict resolver to replace
it (not a triviality by any means).
The only time I'd ever contemplate using a GUID in an Access app is
if the data were not replicated and if there was an outside
requirement for its use.
Otherwise, it should be avoided.
