At 11:09 AM 27/08/2003 +0000, you wrote:

>I have a TIBOQuery, cachedUpdates = True.
>
>SQLs are too big to list here, but contain various blobs.
>The user can via the user interface change the contents of any fields
>including the blobs, and has the option to commit changes or rollback.
>
>When the user commits, the following code is executed:
>
> with fDataset do begin
> try
> if state in [dsEdit, dsInsert] then
> Post;
> DisableControls;
> if UpdatesPending then begin
> result := true;
> ApplyUpdates;
> IB_Transaction.Commit;
> CommitUpdates;
> IB_Transaction.Activate;
> end;
> finally
> EnableControls;
> end;
> end;
>
>If the user modifies a non-blob field and commits, all works fine. If
>he repeatedly does this, all is ok.
>
>If the user modifies a blob field and commits, all works fine.
>If he then modifies the same blob field and commits, again all is ok.
>
>Here comes the bad news ...
>If the user has modified a blob and commited, and then modifies any
>field except the blob and commits, the "ApplyUpdates" fails
>with "Invalid Blob Id".
>
>Any ideas?

Once you call the transaction's CommitUpdates method, the record is gone
from the cache (even though it is still in the dataset buffer).

Blobs aren't actually part of the record structure: they are stored on
their own database pages and linked by the blob_id (which is part of the
record). You never edit blobs: the previous blob image is totally
replaced by a new one and it gets a new blob_id when the "update" is
posted. The new blob_id won't be known in the buffer until you call
Refresh on the dataset. Meanwhile, your user sails on with her second pass
at editing this blob and doesn't discover the invalid (old) blob_id until
the second-time update tries to post.

If you want the new image of the blob to be available for a successive edit
following CommitUpdates, you need to refresh the buffer, so that the new
iblob image, along with its new blob_id, will be re-fetched from the server.

Helen