> 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? 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++)?