Re: Bug report: x64 Row status Array uses wrong data type
От | Inoue, Hiroshi |
---|---|
Тема | Re: Bug report: x64 Row status Array uses wrong data type |
Дата | |
Msg-id | 97ae1e0f-fd75-33ea-b639-3ad92cff1daf@dream.email.ne.jp обсуждение исходный текст |
Ответ на | Bug report: x64 Row status Array uses wrong data type (Jari Siikarla <jari.siikarla@ddswireless.com>) |
Ответы |
Re: Bug report: x64 Row status Array uses wrong data type
RE: Bug report: x64 Row status Array uses wrong data type |
Список | pgsql-odbc |
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.
Where can I find the description that SQL_ATTR_ROW_STATUS_PTR
(or SQL_ATTR_PARAM_STATUS_PTR) doesn't point to an array of
SQLUSMALLINT but SQLSETPOSIROW?
regards,
Hiroshi Inoue
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
В списке pgsql-odbc по дате отправления: