[thelist] Access 2003 and GUID

[Ken Schaefer]

A long int is only 8 bytes, whereas a Replication ID is 16 bytes. So, when 
you convert a long int to a GUID, Access needs to pad the remaining 8 bytes 
with 0

If you want to use GUIDs, you'll need to generate them again.

Generating a GUID (in SQL Server a "uniqueidentifier", in Access a 
"Replication ID", in Windows a GUID) uses functionality provided by Windows 
itself. The GUID itself is generated by taking the current date/time, plus 
the MAC address of the network card, and using that to seed some random 
number generator. Because of the horrendously large number of possible 
values 2^128, (about 3 with 38 zeros on the end), it is extremely unlikely 
that the value will ever be repeated. I think Microsoft states that the same 
value will never be repeated on the same machine across time, though not 
necessarily across space. You will need to check this.

HTH

Cheers
Ken

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Andreas Wahlin" <Andreas.Wahlin at ufl.gu.se>
Subject: [thelist] Access 2003 and GUID


This may seem a silly questionbut the GUID, that is, the Id number in
access databases that look somewhat like {ouo43-3noe-324nh-34n3h4nh}
The acronym stands for Globally Universal IDentifier, which leads me to
believe it's GLOBAL, that is a unique ID in my entire database, and
guaranteed that no two fields have the same ID number in the entire
database. This could let me have a table where I use all the ID's from
all my tables all over without any two being the same.
However, when I convert a long int to this sort of ID number, I get
duplicates over tables since the converted numbers are largely the
original ID number padded with {0000-00-000-0000} to make it look more
GUID like.
So, my question probably is, is the GUID really a globally unique
number, and is the above behaviour only a "bug" when I convert a long
int to a GUID, and if I want to convert my long int id numbers to GUID,
I'll have to delete a record and then add it again (or some other clumsy
way)?
thanks, databases really aren't my strong point