""Ann W. Harrison"" <aharrison@...> wrote in message
news:5.1.0.14.2.20020324114735.023abe30@......

>
> At 10:44 PM 3/23/2002 -0400, Claudio Valderrama C. wrote:
>
> >Isc_cancel_blob is the main way
> >
> >When a blob is created, it's chained to the attachment, to the

transaction

> >and to the linked list of blobs held by the transaction.
>
> And that, probably, is the cause of the problem. Remember that
> a UDF does not inherit transaction or connection context so temporary
> blobs created by a UDF aren't linked into anything. 80% certainty,
> I haven't walked through the code.

I'm sorry, but you're wrong in this case.
The UDF is not calling the API to create a blob. The UDF declaration makes
the engine to provide the placeholder blob to be filled by the udf. When the
application opens that blob, a second temporary blob is created pointing to
the former one, but only copies the vector with the page numbers, it doesn't
mirror again the contents. Once the transaction finishes, both blobs are
cleaned with a call to BLB_cancel originating from TRA_release_transaction,
called in turn by TRA_commit. You just have to debug with patience to
convince yourself. TRA_rollback produces the same effect. You can experiment
with string2blob() in fbudf.

It would be a different story if the UDF tries to call the API directly to
create a blob, but for this it would need (IMHO) to create a connection and
start a transaction.

I'm not saying that blob filters shouldn't be considered. I'm only saying
that the current scenario is not that bad if it's properly managed.

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing