Hi All,

Firebird v2.1.3 (also found on v2.1.2).

I have a few simple udfs that read some information from an
input blob and return a value. The problem described below
occurs on a all UDFs (that take a blob input parameter) that
I have tried. I believe it is an client interface problem
rather than the UDF itself.


The client code is home-grown calling the api from C++. The
code uses dsql_prepare and then dsql_describe and
dsql_describe_bind calls to get field and parameter details.
The code then (apparently) successfully uses the api to create
the blob data and writes the blob_id to the parameter buffer
before calling dsql_execute2 to execute the statement.

The particular problem was found in testing - the SQL below
was not intended for production, just trying out the UDF to
make sure it worked as intended.

Executing this statement:

SELECT ( UDF_PROCESS_BLOB( ? ) ) AS TEST_RESULT
FROM RDB$DATABASE

fails with:
Error 335544358: message length error (encountered 4, expected 12)

The error occurs from the return code after calling
dsql_execute2 (all the previous prepare/describe/blob api
calls seemed to have completed without error).

Obviously in this test situation the blob data is a temporary
blob that never actually exists in a table in the database.
The problem is definitely with the input blob parameter, I've
tried this code with many different udfs and only the ones
taking a blob as input fail this way.


I worked out that I could use execute block to achieve a
successful result:
EXECUTE BLOCK (X BLOB = ? )
RETURNS (TEST_RESULT INTEGER)
AS
BEGIN
SELECT ( UDF_PROCESS_BLOB( :X ) )
FROM RDB$DATABASE
INTO :TEST_RESULT;
SUSPEND;
END

Running that statement through the same client code works as
expected, and since that works it seems to me that my client
code must be correctly handling blob input parameters and the
singleton select result.


Firebird does not come with any UDFs that take a blob as an
input parameter I cannot easily create an example for you to
build and try elsewhere.


Is anyone able to guess from the information given whether
this is really a bug in FB v2.1... or whether I am missing
something?

--
Geoff Worboys
Telesis Computing