Larry,

I believe I have isolated and resolved this problem.

What happens is when a query is re-prepared (not just dealing with changing
RequestLive but other cases as well) and when that happens input parameters
are freed and regenerated. Thus, I have to save off and restore their
values when they are created anew. The way I was doing this wasn't being
sensitive to the possibility of a string with a null character in it.

What I have done is changed this routine to still accept the old format,
because there is stuff stored in people's DFM files in the old format, but I
now use a new format similar to how my bookmarks are produced so that they
don't suffer from this same problem. Now, the data should be preserved
regardless of what is stored.

Jason

> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]On
> Behalf Of larrybaddock
> Sent: Monday, August 15, 2005 2:16 AM
> To: IBObjects@yahoogroups.com
> Subject: [IBO] Subtle Bug in RequestLive setting
>
>
> Hi, All.
>
> There is a subtle bug in the changing of requestlive, in IBO 4.3A. It
> only seems to affect binary (AsRawString) parameters for the query, if
> there is a Character 0 in the parameter. There may be other
> circumstances as well that I am not aware of.
>
> Example, assuming statement is already prepared, and the requestlive
> was initially false for the prepare:
>
> 1 q.RequestLive:=true;
> 2 q.ParamByName('UOID').AsRawString:=#55#56#57#0#58#59;
> 3 q.Open;
> 4 Anything_you_like;
>
> After line 2 is executed, all is still fine. Reading
> 'q.ParamByName('UOID').AsRawString' from the Delphi debugger reveals
> the correct value, of #55#56#57#0#58#59.
> However, as soon as line 3 is executed, the value of
> 'q.ParamByName('UOID').AsRawString' has been silently changed, and now
> gets truncated at the 0, leaving a value of #55#56#57.
> The net result is that at line 4, you assume you are looking at a
> query that contains what you expect, but it actually contains
> something else altogether. The parameter that is sent through to the
> database engine is the truncated value.
>
> Although it does not affect most people (I would imagine that there is
> not a lot of binary data in most database columns outside blobs), it
> is pretty serious if you have a binary GUID, for example, in a 16 byte
> OCTETS field. This type of practice is increasing in popularity.
>
> Anyone who is doing this, for now, be VERY careful, and unprepare the
> query (if the requestlive was initially false, and needs to be true),
> change the requestlive to true and reprepare the query. If you don't,
> be prepared to be bitten.
>
> Jonathan, please have a look into this.
>
> Many thanks
>
> Kind regards
> Larry