>I can't pinpoint your problem exactly, but I'm sure it has to do with 1)
>mismatched data types and 2) the fact that your return parameter has no name.

I tested several things, and to specify a name for the return
parameter doesn't make any difference.

>Your query provides no clue about the SQLType of the input parameters,
>because it is operating neither on database field values (which IBO would
>get from a Prepare) nor on constant values. At Prepare time, there is
>nothing there for the type-casting routine to work with, so it is
>"pot-luck". This problem is typical of what happens with select {something
>unspecified] from rdb$database.

The query uses an udf and in the decleration of the udf the datatypes
are specified. The types of the udf parameters are stored in
rdb$function_arguments.

Why does IBO know the correct datatype of the first 2 parameters and
not the types of all others.

If I have an UDF with for example 5 parameters with different
datatypes and look for the value of ib_query.parambyname
(paramname).sqltype for all parameters, I can see, that the first 2
parameters have the correct sqltypes but all other have the same type
as the second parameter.

Couldn't you try to reproduce it?

I am realy very frustrated now, because I have to look that my project
will be finished soon, and have to resent having to look for the
resolution of such annoying problems.

Yesterday, I was told, that the problem is known as the
parameterordering bug and it will be solved in IBO 4.3, so I bought
IBO 4.3 and I had to see, that it still doesn't work.
I think my problem has nothing to do with the parameterordering bug.

>select test_udf (cast(:a as integer), cast(:b as integer), cast(:c as double))
>as ret_value
>from rdb$database

This statement causes the following errormessage:
Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, char 77
)
Statement: select test_udf (cast(:a as integer), cast(:b as integer),
cast(:c as double))
as ret_value
from rdb$database

PLEASE HELP ME!

cu
Helmut