| Subject | Re: [firebird-support] Re: Question about: SQL error code = -804 Incorrect values within SQLDA structure |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-02-02T12:48:49Z |
At 11:46 AM 2/02/2005 +0000, you wrote:
prepared, the API receives the information about the type and size of the
expected parameters via a container structure (the XSQLDA). The
application then proceeds to place these values into the "slots" (XSQLVAR
structures) prepared for them in the XSQLDA.
There is a bug in IB, and also in Firebird 1, that causes the positional
order to get scrambled, resulting in potential type mismatches between the
values and the parameters. Some older data access interfaces, e.g. IBO
prior to version 4.3A, adjusted for the mis-ordering.
The bug is not present in Firebird 1.5, so those older interfaces now
"cause" scrambling to occur, because they continue to adjust for a
misordering that is not there any more. The Firebird 1.5 server can be
configured to revert to XSQLDA behaviour that emulates the bug (and thus
makes it OK to use those older interfaces). It should be considered a
temporary workaround, of course, since it is a server-wide setting. If you
are using Firebird 1.5 and the current ODBC driver, this won't be the
source of your exception.
The "normal" reason for this exception would be the application passing
data of the wrong type to the parameters; or assigning more (or fewer)
parameters than the SP was expecting (or both...confusion about parameters
usually involves confusion about ordering as well).
Actually, with SPs, use of the word "parameters" makes life confusing. The
proper term for "input parameters" is "arguments", while "output
parameters" are "return values". I'm used to IBO, which keeps the
arguments in one array (named Params) and the return values in another
(named Fields). It's really simple then, since the return values from an
executable procedure (a single-row set) are referenced in the same way as
the output set from a selectable SP (a multi-row set).
If you have the choice to separate the arguments from the return values in
your client code, choose it, so you are clear always when you are referring
to parameters that are arguments vs. those that are return values.
./heLen
>What still bugs me tho, what doesParameter values are passed in a positional order. Once the SP is
>the error mean and why did I came across so many references to an
>old IB bug????
prepared, the API receives the information about the type and size of the
expected parameters via a container structure (the XSQLDA). The
application then proceeds to place these values into the "slots" (XSQLVAR
structures) prepared for them in the XSQLDA.
There is a bug in IB, and also in Firebird 1, that causes the positional
order to get scrambled, resulting in potential type mismatches between the
values and the parameters. Some older data access interfaces, e.g. IBO
prior to version 4.3A, adjusted for the mis-ordering.
The bug is not present in Firebird 1.5, so those older interfaces now
"cause" scrambling to occur, because they continue to adjust for a
misordering that is not there any more. The Firebird 1.5 server can be
configured to revert to XSQLDA behaviour that emulates the bug (and thus
makes it OK to use those older interfaces). It should be considered a
temporary workaround, of course, since it is a server-wide setting. If you
are using Firebird 1.5 and the current ODBC driver, this won't be the
source of your exception.
The "normal" reason for this exception would be the application passing
data of the wrong type to the parameters; or assigning more (or fewer)
parameters than the SP was expecting (or both...confusion about parameters
usually involves confusion about ordering as well).
Actually, with SPs, use of the word "parameters" makes life confusing. The
proper term for "input parameters" is "arguments", while "output
parameters" are "return values". I'm used to IBO, which keeps the
arguments in one array (named Params) and the return values in another
(named Fields). It's really simple then, since the return values from an
executable procedure (a single-row set) are referenced in the same way as
the output set from a selectable SP (a multi-row set).
If you have the choice to separate the arguments from the return values in
your client code, choose it, so you are clear always when you are referring
to parameters that are arguments vs. those that are return values.
./heLen