Subject Re: How to query for a GUID value that is stored as OCTETS?
Author Stefan Renzewitz
--- In, "Ann W. Harrison"
<aharrison@i...> wrote:
> Stefan,
> > Before I was storing the GUID as a simple char(36). Obviously I
> > somehow to convert the GUID into a CHAR(16) with the charset
> I suggest you find (or write) a udf that takes a char(36) string and
> converts it to a char(16) OCTETS hex value. Then the the where
> is "where GUID_FIELD = myConvertFunction(<string>);"
> Regards,
> Ann

Hi Ann,

thanks for your reply. I spent quite some time on this issue and I
found the "solution". Than I googled a little bit more I finally found
a FAQ of a Microsoft Newsgroup there it says something like:
"Any database worth to use should support FBParameters"
"Always use FBParameters" e.g. to avoid escape character problems

This brought me back to my original approach which at first didn't
work, but now it does:

DatabaseHelper.DbCommand.CommandText = "SELECT COUNT(*) FROM
DatabaseHelper.DbCommand.CommandType = System.Data.CommandType.Text;
FbParameter parameter = new FbParameter("@REPERTOIREGUID", FbDbType.
parameter.Direction = ParameterDirection.Input;
parameter.Value = gidRepertoire;
return (Convert.ToInt16(DatabaseHelper.DbCommand.ExecuteScalar())>0);

Then the ADO.NET driver is doing all the work and I don't have to
worry about it anymore.

Nonetheless, before I went back to this approach I tried to write a
converter which almost worked:

Byte[] coBytes = gidRepertoire.ToByteArray();
string coOCTETS = string.Empty;
for(int i=0;i<coBytes.Length;i++)
coOCTETS += Convert.ToChar(coBytes[i]).ToString();

The problem, a few characters like ASCII-Code 7 have a C# specific
escape characater in the string so it still fails when I try to pass
it to CommandText (even when I use something like @).

There should be a work-around I guess.

Anyway, this was a good exercise and I learned quite a bit about
charsets, how useful FBParameters are and a few more things.