RE: [Firebird-net-provider] Guid Support

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

Correct.

	This is not a "real" solution but it is a "real" solution for
those who use GUID as OIDs and looking to migrate from SQL Server to
Firebird.  This is why I suggested having a *compiler flag* -- this is
open source :-).

What I like about open source is that you can construct "real" solutions
that are inconceivable with closed source giving programmers a greater
degree of flexibility.

Clearly if the application/db developer has to support CHAR(16) this
suggestion is of no use but if this is new development -- such as what I
am engaged -- or even a migration project from SqlServer to Firebird --
this "solution" can help speed adoption of Firebird.  I've seen issues
like this used as an excuse or stumbling block.

Of course the "real" solution is for Firebird to support Guids but
taking a cursory glance at their bug/feature list I don't think Guid
support is a high priority task item for them.

Chris

-----Original Message-----
From: Carlos Guzm=E1n =C1lvarez [mailto:car...@te...]=20
Sent: Wednesday, April 28, 2004 12:54 AM
To: ch...@co...
Cc: Peter Jacobi; fir...@li...
Subject: Re: [Firebird-net-provider] Guid Support

Hello:

>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!
>

That is what i was thinking you are doing for implement it,
but that isn't a real solution as people can have a CHAR(16)
field that isn't used for Guid ;)






--
Best regards

Carlos Guzm=E1n =C1lavrze
Vigo-Spain