Bug report: x64 Row status Array uses wrong data type

Jari Siikarla <[email protected]>
Newsgroups gmane.comp.db.postgresql.odbc
Message-ID <08FA934FA252D048A8B6D2018D96549A262C8FE7@CAEX2010.digital-dispatch.com>
Hi

Thank you for psq odbc driver!

I've found an issue with 64 bit driver.
The array returned from fetch for row statuses uses 16 bit values
instead of 64 bit values.

Tested on x64 Windows (7, 10, srv2012 and srv2016)
with 64 bit psqlodbc-09.06.0500 (Unicode and ANSI)
Client is set ODBC version 2



Changing SQLUSMALLINT to SQLSETPOSIROW in descriptor.h
for two structs and in the code handling these structs fixed the issue.
Code in psqlodbc-10.02.0000 is the same for these parts.



struct IRDFields_
{
                           StatementClass                          *stmt;
                           SQLULEN                                     *rowsFetched;
->                        SQLSETPOSIROW                       *rowStatusArray;
                           UInt4                                            nfields;
                           SQLSMALLINT  allocated;
                           FIELD_INFO      **fi;
};

struct IPDFields_
{
                           SQLULEN                                                                 *param_processed_ptr;
->                        SQLSETPOSIROW                                                  *param_status_ptr;
                           SQLSMALLINT                             allocated;
                           ParameterImplClass                  *parameters;
};



Below pseudo code reproduces the issue:

SQLUINTEGER rowsFetched=0;
SQLSETPOSIROW pRowStatus[1];
SQLRETURN retCode;

pRowStatus[0]=-1; // 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF

retCode=SQLSetStmtAttr(hStmt, SQL_ATTR_ROW_ARRAY_SIZE, (SQLPOINTER)1, 0);
retCode=SQLSetStmtAttr(hStmt, SQL_ATTR_ROWS_FETCHED_PTR, &rowsFetched, 0);
retCode=SQLSetStmtAttr(hStmt, SQL_ATTR_ROW_STATUS_PTR, pRowStatus, 0);
retCode=SQLFetchScroll(hStmt, SQL_FETCH_NEXT, 1);

// pRowStatus
// after fetch   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00
// exected to be 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

Thank you,
Jari Siikarla
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.