The ODBC Driver Manager does not convert Unicode parameter data to ANSI during a call to the ODBC API
SQLBindParameter, even when the ODBC driver involved is ANSI. If the ANSI driver saves this parameter data (that is in Unicode format) into its own internal buffer and tries to use it later, the results could be unpredictable. This problem also affects the parameter length, since Unicode strings require twice the buffer space of ANSI strings.
The ODBC driver should wait until a
SQLExecute or
SQLExecDirect call is made. ODBC drivers should not store parameter data or length information during the call to
SQLBindParameter.
This behavior is by design.
When a Unicode application calls
SQLBindParameter in an ANSI driver, the ODBC Driver Manager does not immediately convert the Unicode parameter data to ANSI. The Driver Manager does an in-place conversion to ANSI only during the call to
SQLExecute or
SQLExecDirect, and then immediately converts the parameters back to Unicode. This is how the Driver Manager handles compatibility between Unicode applications and ANSI drivers.
It is risky if the ANSI driver saves this parameter data while it is still in Unicode format (before the
SQLExecute or
SQLExecDirect call) and then tries to use it later.
As per the ODBC specification, the
ParameterValuePtr, which is one of the input parameters to the
SQLBindParameter, is defined as follows:
The ParameterValuePtr argument points to a buffer that, when SQLExecute or SQLExecDirect is called, contains the actual data for the parameter.
Microsoft ODBC 3.0 Programmer's Reference and SDK Guide, topic: "SQLBindParameter"; (Chapter 21)