Geoff

Thanks for getting to the bottom of this.

In my view if it isn't a bug it's an unacceptable consequence of the way IB
works.

With regard to your suggestion for a full fix - how about the TIB_Dataset
doing a refetch only if there is more than one blob field in the record?

Regards
Paul

> Problem Summary: Two blob fields on a TIB_Cursor. Change one blob
> and post the change. Change the other blob and post the change.
> After this both appear to contain the same data (the most recently
> changed blob). In some circumstances it can also result in "Invalid
> Blob ID" exceptions.
>
> Note: I believe you would still see the problem even if the blob
> fields were on different cursors (but attached to the same
> transaction).
>
>
> Short Answer:
>
> You can work around the problem by doing a refresh immediately after
> performing the post. Alternatively you can simply use TIB_Query (but
> setup so that is only buffers the one record by retrieving for the
> specific key value). We need to wait for Jason to confirm whether
> this should be considered a bug or working by design (I suspect the
> latter).
>
>
> Long Answer:
>
> The problem results from a peculiarity in the way that the IB API
> manages blobs. When you post changes to a record containing blobs,
> the process is performed in two stages.
>
> 1. Blobs are saved to the database, in the processing returning a
> unique blob identifier value (BlobID). The problem comes from the
> fact that at this stage in the processing, the BlobID returned by the
> API is a "temporary" identifier - it is NOT the one that will
> eventually be stored on the record itself.
>
> 2. The record itself is posted to the database - including a
> reference to the temporary BlobID value. The database then creates a
> new permanent BlobID for given temporary blob reference and it is the
> new BlobID that is stored in the database.
>
> The symptoms that you are seeing come about because, after stage two
> is completed, IB thinks that the old temporary blobid is no longer in
> use - and it happily reuses it for your next blob update. Inside the
> IBO record buffer this results two blobs referencing the same
> temporary storage space - thus appearing to contain the same data.
>
> The IBO buffered datasets (TIB_Query, TIBO* etc) monitor the
> processing to check for temporary blobid values, and if they exist it
> automatically does a fetch of the record data after posting so that it
> can get the new permanent BlobID values. (Regardless of the
> BufferSynchroFlag settings.)
>
> The unbuffered datasets (TIB_Cursor) do NOT have this check. This is
> probably by design. That is; TIB_Cursor is designed for maximum
> performance, so Jason avoids any unnecessary overheads - such as
> refreshing the record buffer automatically after posting changes.
>
> I had thought that we may be able to create a work around by having
> TIB_Cursor check the temporaryblobid flag and automatically refetch
> the record before going back into edit mode. However this would not
> completely resolve the issue. The temporary blob ids are created
> without reference to the statement/dataset. They only use the
> reference to the database and the transaction. So the problem would
> exist even if the two blobs were on different cursors against the same
> transaction.
>
> AFAICT the only full "fix" would be to have TIB_Dataset (the base for
> TIB_Cursor) automatically do a refetch of the record after posting -
> as the buffered dataset does now. However such automation would
> impact all instances of TIB_Cursor, even those where the problem does
> not matter (which I think would be most instances).
>
> The result being that I think my short answer was the best :-) Do a
> refresh immediately after posting your TIB_Cursor.
>
>
>
> HTH
>
> Geoff Worboys
> Telesis Computing
>