Jerry Sands wrote:

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

Your own data should never appear as temporary blob fields ...
should it? (Or have I missed something somewhere?) The
MON$STATEMENT.MON$SQL_TEXT field is for the statement text,
not for the field content (or so I assume from what I've
read, I've not used it myself yet). In which case it should
usually be very small, and always of some quite limited size
(compiles to less than 64kb would be my guess at the limit).

Such limited fields should be okay to automatically load,
making the usual requirements fairly simple to deal with, with
no special/extra action on the developers part. It is only
if there are other temporary blobs that might get big (I've
not studied this API in detail to see what else there may be)
that auto-load could become an issue, and so only in such odd
situations require special action on the part of the app.

--
Geoff Worboys
Telesis Computing Pty Ltd