GUID type support in for ODBC/C++/GUID as replacement for autonumber fields

GUID type support in for ODBC/C++/GUID as replacement for autonumber fields

Post by Randy Bake » Thu, 14 Aug 1997 04:00:00



I have pored over the header files and searched MSDN and don't see an
obvious way to bind to GUID fields in Access or SQL Server tables. I
suppose you could bind to a CByteArray, but this seems a ludicrous amount
of overhead to support 16 byte values.

Does anyone have any experience with this? We are trying to port an Access
application to ODBC (specifically SQL Server), and the GUID type seemed a
logical replacement for our use of autonumber fields. I know that we could
also use IDENTITY columns, but we also use our counters for referential
integrity and GUID's would seem to have the natural advantage of being
(optionally) generated prior to actually writing the records.

Thanks,

--
Randy Baker (remove Z from address in email replies)

 
 
 

GUID type support in for ODBC/C++/GUID as replacement for autonumber fields

Post by Randy Bake » Thu, 14 Aug 1997 04:00:00


To be more specific, the GUID's are implemented by specifying ReplicaID as
the size of numeric fields.

Interestingly, when I upsize a table with a ReplicaID length number field
to SQL Server, the resulting SQL Server field is type is "varbinary". Go
figure.
--
Randy Baker (remove Z from address in email replies)



Quote:> I have pored over the header files and searched MSDN and don't see an
> obvious way to bind to GUID fields in Access or SQL Server tables. I
> suppose you could bind to a CByteArray, but this seems a ludicrous amount
> of overhead to support 16 byte values.

> Does anyone have any experience with this? We are trying to port an
Access
> application to ODBC (specifically SQL Server), and the GUID type seemed a
> logical replacement for our use of autonumber fields. I know that we
could
> also use IDENTITY columns, but we also use our counters for referential
> integrity and GUID's would seem to have the natural advantage of being
> (optionally) generated prior to actually writing the records.

> Thanks,

> --
> Randy Baker (remove Z from address in email replies)


 
 
 

GUID type support in for ODBC/C++/GUID as replacement for autonumber fields

Post by Randy Bake » Thu, 14 Aug 1997 04:00:00


A little more experimentation reveals that you can bind a field of type
dbGUID to a CString, but this is for output only. If you do nothing more
than mark the same data you just read as dirty and attempt an update, you
get a data type conversion error.

Obviously, this works fine for auto-number fields, since these can't be
updated anyway. But you can have an non-autogenerated number that you
supply the data for yourself, and I can edit this value from the Access
grid, so how is one to update these fields from MFC?

--
Randy Baker (remove Z from address in email replies)



Quote:> I have pored over the header files and searched MSDN and don't see an
> obvious way to bind to GUID fields in Access or SQL Server tables. I
> suppose you could bind to a CByteArray, but this seems a ludicrous amount
> of overhead to support 16 byte values.

> Does anyone have any experience with this? We are trying to port an
Access
> application to ODBC (specifically SQL Server), and the GUID type seemed a
> logical replacement for our use of autonumber fields. I know that we
could
> also use IDENTITY columns, but we also use our counters for referential
> integrity and GUID's would seem to have the natural advantage of being
> (optionally) generated prior to actually writing the records.

> Thanks,

> --
> Randy Baker (remove Z from address in email replies)

 
 
 

1. GUID type support in for ODBC/C++/GUID as replacement for autonumber fields

I have pored over the header files and searched MSDN and don't see an
obvious way to bind to GUID fields in Access or SQL Server tables. I
suppose you could bind to a CByteArray, but this seems a ludicrous amount
of overhead to support 16 byte values.

Does anyone have any experience with this? We are trying to port an Access
application to ODBC (specifically SQL Server), and the GUID type seemed a
logical replacement for our use of autonumber fields. I know that we could
also use IDENTITY columns, but we also use our counters for referential
integrity and GUID's would seem to have the natural advantage of being
(optionally) generated prior to actually writing the records.

Thanks,

--
Randy Baker (remove Z from address in email replies)

2. Launching an app on the server

3. D3/Access: Need Support for Access 97/DAO3.5/GUID types

4. How to "Defragment" Tablespaces ?

5. GUID and addNew - can't get back the GUID value

6. how to intercept "related file missing" by script?

7. Using a GUID as a Primary Key or indexing a GUID

8. Different return values when using Query Analyzer and VB code

9. AddNew with a GUID - can't get back the GUID

10. Using a GUID as a Primary Key or indexing a GUID

11. Design question: Key type (guid or alpha field)

12. How to use ADO and SQL7 GUID type for primary key field