An open-source ODBC driver manager and SDK that facilitates the development of database-independent applications on linux, freebsd, unix and MacOS X platforms.
I have a scenario where I'm binding a parameter as SQL_C_WCHAR/SQL_PARAM_INPUT_OUTPUT & with a length indicator set to SQL_DEFAULT_PARAM.
it seems that _SQLExecute_ConvParams/_ConvParam doesn't handle SQL_DEFAULT_PARAM properly, as at the following stack, it's trying to 'convert'(as in #66, the DM encoding matches the driver encoding...) the buffer I bound to the parameter (which happens to be full of zeroes, and isn't meant to be used as input as all), and then overwrites my length indicator with 0. This causes the driver to receive the wrong input parameter value.
frame #0: 0x000000010452f17c libiodbc.2.dylib`_ExecConv_W2W(data="", pInd=0x0000000104833498, size=1024, conv=0x0000000104609d6c, bOutput=NO) at execute.c:378.29
frame #1: 0x000000010452ee24 libiodbc.2.dylib`_ConvParam(pstmt=0x0000000104619190, pparm=0x000000011700ae00, row=0, bOutput=NO, conv=0x0000000104609d6c, unicode_driver=1) at execute.c:448:5
frame #2: 0x000000010452c280 libiodbc.2.dylib`_SQLExecute_ConvParams(hstmt=0x0000000104619190, bOutput=NO) at execute.c:983:17
frame #3: 0x000000010452acfc libiodbc.2.dylib`SQLExecute_Internal(hstmt=0x0000000104619190) at execute.c:1072:13
frame #4: 0x000000010452ab4c libiodbc.2.dylib`SQLExecute(hstmt=0x0000000104619190) at execute.c:1166:13
I have a scenario where I'm binding a parameter as SQL_C_WCHAR/SQL_PARAM_INPUT_OUTPUT & with a length indicator set to SQL_DEFAULT_PARAM.
it seems that
_SQLExecute_ConvParams/_ConvParamdoesn't handle SQL_DEFAULT_PARAM properly, as at the following stack, it's trying to 'convert'(as in #66, the DM encoding matches the driver encoding...) the buffer I bound to the parameter (which happens to be full of zeroes, and isn't meant to be used as input as all), and then overwrites my length indicator with 0. This causes the driver to receive the wrong input parameter value.