Microsoft Office Tutorials and References
In Depth Information
Access Data Types
Using replication IDs
Imagine you’re working at a company with several regional sales offices, each with
its own database for tracking customers. If you use an ordinary AutoNumber field,
then you’ll end up with several customers with the same ID, but at different offices.
If you ever want to compare data, you’ll quickly become confused. And you can’t
combine all the data into one database for further analysis later on.
Access gives you another choice—a replication ID. A replication ID is a strange
creation—it’s an extremely large number (16 bytes in all) that’s represented as a string
of numbers and letters that looks like this:
This ID is obviously more cumbersome than an ordinary integer. After all, it’s much
easier to thank someone for submitting Order 4657 than Order 38A94E7B-2F95-
4E7D-8AF1-DB5B35F9700C. In other words, if you use the AutoNumber value for
tracking or bookkeeping, then the replication ID is a bad idea.
However, the replication ID solves the problem described earlier, where multiple
copies of the same database are being used in different places. That’s because
replication IDs are guaranteed to be statistically unique. In other words, there are so many
possible replication IDs that it’s absurdly unlikely that you’ll ever generate the same
replication ID twice. So even if you have dozens of separate copies of your database,
and they’re all managing hundreds of customers, you can rest assured that each
customer has a unique customer ID.
Note: A replication ID is also called a GUID (short for “globally unique identifier”). In theory, the chances
of two GUIDs being identical are one in 2 , which is small enough that you could set one billion people to
work, ask them to create one billion GUIDs a year, and still be duplicate-free for the next decade or two. In
practice, the real limitation is how good the random number generator is in Access.
Figure 26-20 shows a table that uses replication IDs.
This figure shows four records in the
FictionalCharacters table, each with
a statistically unique AutoNumber