RE: [Firebird-net-provider] Guid Support

[Chris W. <ch...@co...>]

Hi Peter,


>Only CHARACTER SET OCTETS is designed to be a mere array of bytes,
>so that I'm curious whether your test worked without specifying the
>character set.

[1] You are very much correct to point out and bring up the impact that
Firebird character set has on altering CHAR(N) definitions.  Currently
I am using the default character set for Firebird (in other words I did
not set the character set and therefore presuming ascii) that by default
treats CHAR(N) as a stream of 16 bytes. 

Since I just noticed your email I will go back and redefine my columns
to 

CHAR(16) CHARACTER SET OCTETS

I'm confident it will work and I'll let you know the results.

In addition I also tested using Guid.Empty and it works flawlessly.  I
use
Guid.Empty to indicate to Firebird to insert the record.  A valid Guid
is used to indicate update.   Also I use a UDF to generate a new Guid
during inserts.

Thanks for your observation and input.
Chris

-----Original Message-----
From: Peter Jacobi [mailto:pj...@wa...] 
Sent: Wednesday, April 28, 2004 12:39 AM
To: ch...@co...
Cc: fir...@li...
Subject: Re: [Firebird-net-provider] Guid Support

Hi Chris,

> I've tried storing this with Firebird and it seems to work.  

Did your test include cases where the GUID did contain
bytes of value zero? On average 1/16th of all GUID of
should have this "feature"?

> Firebird seem
> to treat CHAR types as merely as an array of bytes and doesn't seem to
> attempt any other interpretations.  

Only CHARACTER SET OCTETS is designed to be a mere array of bytes,
so that I'm curious whether your test worked without specifying the
character set.

> With that knowledge and if you are
> developing a new database project make it a guideline that only GUID
> entities are defined as CHAR(16).

CHAR(16) CHARACTER SET OCTETS

> The only issue is reading from Firebird into the .NET provider as it
will
> "think" a GUID is a Firebird TEXT type.  The way for the provider to
> distinguish that the data coming across is a guid is for the provider
to
> check the size.  If the data is TEXT by and size is 16 then assume a
GUID
> and convert the byte stream to a GUID -- wal-la!

I don't know whether the provider already includes special casing
for character set octets, perhaps Carlos should comment on this.

Also short of adding a new type, a new (pseudo) character set can
be created, which behaves mostly like OCTETS but uniquely identifies
the field as being an GUID. It's even possible to make the
stringification
of the GUID a character set conversion to ASCII, if this buys anything.

Regards,
Peter Jacobi