Re: [ODBC] ODBC large binary data support

Поиск
Список
Период
Сортировка
От Inoue, Hiroshi
Тема Re: [ODBC] ODBC large binary data support
Дата
Msg-id 676d0c62-c645-e466-7d12-5c88019c15fb@dream.email.ne.jp
обсуждение исходный текст
Ответ на Re: [ODBC] ODBC large binary data support  (myaddress@gmx-topmail.de)
Список pgsql-odbc
Thanks for the report.
I would commit the change soon.

On 2017/01/10 16:29, myaddress@gmx-topmail.de wrote:
Dear Hiroshi Inoue,
 
The new update fixed my issues. It's also working with the 32-bit version now. The Microsoft documentation concerning SQL_NO_TOTAL is a little bit strange in my eyes.
So, I don't know what the "correct" behavior is for the 32-bit version and data >2GB. My feeling teels me that SQL_NO_TOTAL is "correcter" than 0x7fffffff. So I'd say the current version is good.
When will you officially release it?


As for SQL_NO_TOTAL, look at the page https://msdn.microsoft.com/en-us/library/ms715441(v=vs.85).aspx.

7. Places the length of the data in *StrLen_or_IndPtr. If StrLen_or_IndPtr was a null pointer, SQLGetData does not return the length.     For character or binary data, this is the length of the data after conversion and before truncation due to BufferLength. If the driver
    cannot determine the length of the data after conversion, as is sometimes the case with long data, it returns
    SQL_SUCCESS_WITH_INFO and sets the length to SQL_NO_TOTAL. (The last call to SQLGetData must always return the length of the
    data, not zero or SQL_NO_TOTAL.)

The test driversI return SQL_NO_TOTAL while the length of the rest of the data is outside the range of SQLLEN.

regards,
Hiroshi Inoue

В списке pgsql-odbc по дате отправления:

Предыдущее
От: myaddress@gmx-topmail.de
Дата:
Сообщение: Re: [ODBC] ODBC large binary data support
Следующее
От: "martin.baumgaertner"
Дата:
Сообщение: [ODBC] have you seen that already?