At 03:52 PM 30/11/2007, you wrote:

>>
>> >I am using the FreeAdhocUDF which can be downloaded from
>> >http://www.udf.adhoc-data.de/index_eng.html
>> >
>> >We've tested the latest version. We found that after UDF calls, the
>> >memory was not released until the connection to database is closed.
> > 2. what your declaration of the UDF looks like.
>
>DECLARE EXTERNAL FUNCTION F_STRINGLENGTH
> CSTRING(254)
> RETURNS INTEGER FREE_IT
> ENTRY_POINT 'stringlength' MODULE_NAME 'FreeAdhocUDF';

This is the wrong declaration for a function that passes a string and returns an integer. The return value never gets lifted off the stack. (FREE_IT is used to release memory that has been allocated by the UDF for a *returned* string...)

It should look more like this (without testing, because I can't at the moment):

DECLARE EXTERNAL FUNCTION F_STRINGLENGTH
CSTRING(254)
RETURNS INTEGER BY VALUE
ENTRY_POINT 'stringlength' MODULE_NAME 'FreeAdhocUDF';

or

DECLARE EXTERNAL FUNCTION F_STRINGLENGTH
CSTRING(254),
INTEGER
RETURNS parameter 2
ENTRY_POINT 'stringlength' MODULE_NAME 'FreeAdhocUDF';

Also make sure that the number of BYTES in the string that you are passing TO the UDF is not larger than the declared 254 bytes. (You can make multiple declarations of the same UDF, using different external names, if you need to declare a bigger input parameter to accommodate more bytes.)

If you got this declaration from an SQL script supplied by the authors of the UDF library, you had better alert them to the mistakes. Your problem could also be hiding an error in the UDF code that is causing strings not to be cleaned up in a thread-safe manner.

You could alternatively use Firebird's own STRLEN() function (in ib_udf) to be on the safe side.

./heLen