Hi,

> > UDF's do not have database context. They don't know what
> connection
> > or what transaction they belong to. They can create temporary
> blobs,
> > because temporary blobs are outside normal database context. To
> use
> > UDF's to read or write data, you must make a separate connection
> and
> > start a transaction. That transaction can deadlock against the
> client
> > transaction that invoked the UDF, so that's messy.
> >
> > Stored procedures run in the context of the transaction that
> started
> > them.
>
> I was fooling around with UDF's, and looking into the ibpp library,
> and it seemed that ibpp could be very useful for UDF's (eg: nice
> wrappers for blobs, arrays, etc). But all the ibpp objects need a db
> connection and transaction context.
>
> So I wrapped my UDF with a stored proc, then passed down
> CURRENT_CONNECTION and CURRENT_TRANSACTION to the UDF, at which
> point (theoretically anyway) all the ibpp functionality should be
> available without requiring a separate database connection (hence,
> no deadlock).
>
> Am I off-base here?

Yes. Very.

CURRENT_CONNECTION and CURRENT_TRANSACTION
aren't valid handles (which you can use for the external Firebird API),
but rather internal counters.

>If not, is there any other reason a UDF
> shouldn't be used instead of a sproc (I'd rather use a sproc, since
> their easier to maintain, but some things need to or should be done
> in C/C++)?

External Functions should call back into the database. Plain and
simple.

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com