Jason wrote:

[...]

> 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.

[...]

Geoff wrote:

>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.

Now that I understand what is happening I would agree with Geoff. The
developer can handle the blobs in a way that fits the application. If a
blob needs to be fetched after a transaction commits a refresh of the row
should get a fresh blob id. In my example from the MON$ table there
probably would not be more than a few hundred rows max involved with blobs
on the small side (I wonder why the Firebird developers did not just use a
large varchar for that?). On the next application I will be writing there
will be 30-50 thousand rows with scanned documents in the blobs which will
be much larger and a different approach will be necessary so I doubt a one
size fits all would be the answer.

Thanks to both Jason and Geoff!

Jerry Sands



[Non-text portions of this message have been removed]