Subject | Re: How to query for a GUID value that is stored as OCTETS? |
---|---|
Author | Stefan Renzewitz |
Post date | 2005-08-08T09:26:44Z |
--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@i...> wrote:
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"
and
"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
REPERTOIRE WHERE REPERTOIREGUID = @REPERTOIREGUID";
DatabaseHelper.DbCommand.CommandType = System.Data.CommandType.Text;
FbParameter parameter = new FbParameter("@REPERTOIREGUID", FbDbType.
Guid);
parameter.Direction = ParameterDirection.Input;
parameter.Value = gidRepertoire;
DatabaseHelper.DbCommand.Parameters.Add(parameter);
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.
Stefan
<aharrison@i...> wrote:
> Stefan,have
>
> > Before I was storing the GUID as a simple char(36). Obviously I
> > somehow to convert the GUID into a CHAR(16) with the charsetOCTETS.
>clause
> 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>);"Hi Ann,
>
>
> Regards,
>
>
> 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"
and
"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
REPERTOIRE WHERE REPERTOIREGUID = @REPERTOIREGUID";
DatabaseHelper.DbCommand.CommandType = System.Data.CommandType.Text;
FbParameter parameter = new FbParameter("@REPERTOIREGUID", FbDbType.
Guid);
parameter.Direction = ParameterDirection.Input;
parameter.Value = gidRepertoire;
DatabaseHelper.DbCommand.Parameters.Add(parameter);
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.
Stefan