[...]

> This can be resolved by automatically retrieving the blob
> contents at the time of fetching the record or by me putting
> yet additional constraints upon keeping the transaction open
> until it is safe to let it go.

> There are advantages and disadvantages to both of these
> approaches. The first one would be very easy to do and I can
> do it today. The second one would take a considerable amount
> of doing and add to the complexity of the IBO engine
> significantly.

[...]

I don't have much experience with the MON$ stuff yet, but if
it's fairly safe to assume such blobs will be relatively small
then I would definitely vote for the less complex solution.

Perhaps, as some sort of built-in protection, such auto-loading
of temporary blobs could be limited to some realistic size
(100kB?). Anything larger than that would not be auto-loaded
and it would be up to the programmer to deal with any such
anomalous situations. ... Which is, of course, the third
solution that you didn't mention:

Now that you've identified the problem you could divert the
solution to the application. When dealing with MON$ fields you
could leave it up to the programmer - to either make sure that
they load anything from blobs that they might want before the
transaction closes, or they make sure the transaction doesn't
close until are done. Not perfectly pretty, but not totally
unrealistic either - I don't see a lot wrong with asking the
developer to take explicit control over the transaction in such
specific situations.

--
Geoff Worboys
Telesis Computing Pty Ltd