You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the previous binding system with "dbstmt.bindParam" is DEPRECATED, I use for the first time the new "dbstmt.bindParameters()".
But, I had some issues while converting the existing call to the new version, which are not documented, especially with numeric values and return values:
For IN parameters in numeric format, it is imperative to put the right type of data in the parameter table. If a number is expected, for example, '3' does not work, it is absolutely necessary to put 3. The problem arises if we retrieve data from an SQL SELECT, where all the numeric data are returned by default in the form of a string.
Otherwise, either at a minimum the stored procedure does not receive the value, and at worst, the stored procedure is simply not called, without any error message.
For an OUT parameter in numerical format, it is even more true, because otherwise we get an error message: QLSTATE=22504 SQLCODE=-191 Mixed data or UTF-8 data not properly formed.
For an OUT parameter of type CHAR(N), it is imperative to provide a string of N characters, like ' '. padEnd (N, ' '), in order not to recover parasitic characters.
In my test, for an out parameter MSGR A(132), while i was waiting for a "OK", I got strings like "OK F&REFD=00011368\u0001�;'�"]" or "OK �J��"
The text was updated successfully, but these errors were encountered:
**idb-connector version : 1.213 **
As the previous binding system with "dbstmt.bindParam" is DEPRECATED, I use for the first time the new "dbstmt.bindParameters()".
But, I had some issues while converting the existing call to the new version, which are not documented, especially with numeric values and return values:
Otherwise, either at a minimum the stored procedure does not receive the value, and at worst, the stored procedure is simply not called, without any error message.
For an OUT parameter in numerical format, it is even more true, because otherwise we get an error message:
QLSTATE=22504 SQLCODE=-191 Mixed data or UTF-8 data not properly formed.
For an OUT parameter of type CHAR(N), it is imperative to provide a string of N characters, like
' '. padEnd (N, ' ')
, in order not to recover parasitic characters.In my test, for an out parameter MSGR A(132), while i was waiting for a "OK", I got strings like "OK F&REFD=00011368\u0001�;'�"]" or "OK �J��"
The text was updated successfully, but these errors were encountered: