Re: Bug report: x64 Row status Array uses wrong data type

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