The information in this article applies to:
SUMMARY
AdoGUIDz.exe is a self-extracting executable that contains a sample project
that demonstrates using the globally unique identifier datatype (GUID)
with Microsoft Access, SQL 6.5 and SQL 7.0. The sample code may be
particularly helpful if you are attempting to manipulate GUIDs with ODBC
versions 3.51 and below because those versions of ODBC do not support a
native GUID datatype. ODBC versions 3.6 and above include the GUID
datatype. Consequently, the methods for manipulating GUIDs with ODBC 3.6
are simpler.
MORE INFORMATIONThe following files are available for download from the Microsoft
Download Center. Click the file names below to download the files: Adoguidz.exeRelease Date: DEC-29-1998 For more information about how to download files from the Microsoft Download Center, please visit the Download Center at the following Web address http://www.microsoft.com/downloads/search.aspand then click How to use the Microsoft Download Center.
Microsoft Access has a ReplicationID AutoNumber field that is a 16-byte
(128 bit) Globally Unique Identifier (GUID) that uniquely identifies each
record in the database. Please reference the sample project for the code
that demonstrates how to SELECT specific GUIDs and Insert GUIDs using the
AutoNumber field with Microsoft Access. The following function is a code
snippet from the sample that demonstrates how to SELECT a specific GUID
from an Access table using Microsoft ActiveX Data Objects (ADO):
Sample Code
Unlike SQL 6.5, SQL 7.0 supports a GUID datatype known as UNIQUEIDENTIFIER. This datatype is a 16-byte GUID stored in the same format as the Microsoft Access AutoNumber (GUID) datatype. There are subtle differences concerning how to Insert and Retrieve the GUIDs among the different database engines. Since SQL 6.5 does not support a native GUID datatype the methods used for storing/retrieving GUIDs are much different than SQL 7.0 or Microsoft Access. SQL 7.0 with the OLEDB provider is almost the same as Microsoft Access with or without the OLEDB provider (SQLOLEDB), as you will see in the sample code. With SQL 6.5 you must store the GUID as a VarBinary(16) datatype. Consequently, to retrieve the GUID with SQL65 you must use a stored procedure and build a Command object with the appropriate ByteArray parameter to pass to the stored procedure SELECT statement. NOTE: You must use the same code techniques with SQL 7.0 as with SQL 6.5 if you are using the ODBC provider (MSDASQL) since in ODBC 3.51 and below the GUID datatype is not recognized. The 16-byte (128 bit) data structure of a GUID:
To demonstrate GUIDs with SQL 7.0 or SQL 6.5 in the sample project you must
specify a valid (test) SQL 7.0/SQL 6.5 server and database. To do so,
navigate to the Connection Info tab and change the Server and Database
reference. The defaults are (local) Server and the Pubs database. Also, to
use the native GUID datatype for SQL 7.0, you must change to the OLEDB
provider (SQLOLEDB) by clicking the appropriate option button in the
Provider frame at the top of the Form. If you select ODBC as the provider
for SQL 7.0 then the application uses the same code as with SQL 6.5.
NOTE: The Connection Info tab has no bearing on Microsoft Access. The default database for Microsoft Access is included with the sample project AadoGUID.mdb as should reside in the Application path. For each database you select in the sample project you must run Create Table to create the GUID test table and then Insert to automatically generate some test GUID data before running a ReQuery. NOTE: CoCreateGUID() is called in the Insert sample code to generate the test GUID values. In the sample application there is a ByteArray2GUID() function that is used to convert the VarBinary(16) byte array to a GUID string for display. Also, the function is used to convert the GUID string to a byte array for storage in the SQLServer VarBinary(16) datatype column. Note that the function is needed when using the GUIDs interchangeably between Microsoft Access and SQL 6.5. If you Export the Microsoft Access table to SQL 6.5 you will see that the bytes are not stored in the same order in which they display in the Microsoft Access table view. For example:
NOTE: The bytes are in (DWord and Word) reverse order after Exporting the
Microsoft Access table.
Because the Microsoft Access Upsizing Wizard results in the same storage of the bytes in SQL 6.5, you must use the ByteArray2GUID() and GUID2ByteArray() functions to remain compatible with the storage of the GUIDs in Microsoft Access. If you do not need to Export the Microsoft Access table to SQL 6.5 or upsize the Microsoft Access database to SQL 6.5 then you need only store the bytes in a straightforward fashion. The following is a code snippet from the code sample that demonstrates the storage of the GUID in the byte format of Microsoft Access. Sample Code
REFERENCESFor more information, please see the following article in the Microsoft Knowledge Base: Q176790 : HOWTO: Use CoCreateGUID API to Generate a GUID with VBMicrosoft SQL 7.0 Books Online; search on: "UNIQUEIDENTIFIER" Microsoft SQL 6.5 Books Online; search on: "VarBinary" Microsoft Access Help; search on: "ReplicationID - AutoNumber field" © Microsoft Corporation 1999, All Rights Reserved. Additional query words:
Keywords : kbfile kbAccess kbADO200 kbDatabase kbSQLServ kbVBp500 kbVBp600 kbGrpVBDB kbGrpMDAC kbDSupport kbADO210sp2 |
Last Reviewed: December 16, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |