Very Computer

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)

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)

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)