Re: SQLGetData() returns len 4095 for empty TEXT on AIX 6.1 without ClientCharset defined

Sorry:

After a closer look I don't use column-wise binding if a text/byte
column is in the result set.

Seb

On 03/18/2013 10:04 AM, Sebastien FLAESCH wrote:
> OK.
>
> FYI, I am using column-wise binding with:
>
>       rcode = SQLSetStmtAttr(m_hstmt_2, SQL_ATTR_ROW_BIND_TYPE,
>                              (SQLPOINTER) SQL_BIND_BY_COLUMN, SQL_IS_UINTEGER);
>
>       rcode = SQLSetStmtAttr(m_hstmt_2, SQL_ATTR_ROW_ARRAY_SIZE,
>                              (SQLPOINTER) ARRAY_SIZE, SQL_IS_UINTEGER);
>
>       rcode = SQLSetStmtAttr(m_hstmt_2, SQL_ATTR_ROWS_FETCHED_PTR,
>                              (SQLPOINTER)&  (nrows), SQL_IS_UINTEGER);
>
> I will try to reproduce with a small sample.
>
> Seb
>
> On 03/16/2013 03:04 PM, Frediano Ziglio wrote:
>> 2013/3/14 Sebastien FLAESCH<[email protected]>:
>>> Hi,
>>>
>>> I have already reported an issue regarding SQLGetData()/iconv, see mails with title:
>>>
>>> "SQLGetData() returns TEXT length minus one on Solaris 64b with SQL Server 2005"
>>>
>>> But now we have a similar problem on AIX 6.1, still with version 0.92.377.
>>>
>>> After inserting an empty TEXT, we fetch it back (see mail history for details),
>>> and SQLGetData() returns a len of 4095 bytes, when zero is expected.
>>>
>>
>> I downloaded 0.92.377, forced indirect conversion and checked
>> SQLGetData with empty text (there is also a spcific test in getdata
>> test but I enhanced it) but unfortunately was not able to reproduce
>> your result (getting 4095 for an empty string). Could you help repro
>> the case? Or I didn't understand your problem?
>>
>>> This occurs if no ClientCharset is defined in the ODBC data source...
>>>
>>> When setting:
>>>
>>>       ClientCharset = en_US.8859-15
>>>
>>> or:
>>>
>>>       ClientCharset = en_US.UTF-8
>>>
>>> The len returned by SQLGetData() is zero, as expected.
>>>
>>> Some news about this?
>>>
>>> As I suggested, if there is some iconv conversion issues, FreeTDS should stop
>>> with a fatal error, to avoid any data loss / mis-conversion. It should not
>>> silently send or return invalid character data.
>>>
>>> Seb
>>>
>>>
>>
>> Mmm... from my log
>>
>> 13:44:19.515397 (token.c:321):looking for login token, got  ad(LOGINACK)
>> 13:44:19.515401 (token.c:357):server reports TDS version 71.0.0.1
>> 13:44:19.515404 (token.c:359):Product name for 0x71000001 is 2000 SP1
>> 13:44:19.515409 (token.c:391):Product version 89001388
>> 13:44:19.515413 (token.c:321):looking for login token, got  e3(ENVCHANGE)
>> 13:44:19.515417 (token.c:107):tds_process_default_tokens() marker is
>> e3(ENVCHANGE)
>> 13:44:19.515422 (token.c:2045):changing block size from 4096 to 4096
>> 13:44:19.515426 (token.c:321):looking for login token, got  fd(DONE)
>> 13:44:19.515430 (token.c:107):tds_process_default_tokens() marker is fd(DONE)
>> 13:44:19.515435 (token.c:1905):tds_process_end: more_results = 0
>>                   was_cancelled = 0
>>                   error = 0
>>                   done_count_valid = 0
>> 13:44:19.515440 (token.c:1921):                rows_affected = 0
>> 13:44:19.515443 (token.c:1924):tds_process_end() state set to TDS_IDLE
>> 13:44:19.515448 (token.c:423):tds_process_login_tokens() returning TDS_SUCCESS
>> 13:44:19.515467 (iconv.c:967):tds_iconv_get: what is charset "en_US.8859-15"?
>> 13:44:19.515475 (odbc.c:1723):SQLAllocStmt(0x207f380, 0x606de0)
>> 13:44:19.515479 (odbc.c:1621):_SQLAllocStmt(0x207f380, 0x606de0)
>>
>>
>> As you reported another charset is silently used. Also strangely seems
>> that client charset is readed after the login. Oh, probably cause is
>> used only to convert data as now wide is the default and UTF-8 is used
>> in libTDS. Yes, that is, disabling wide cause connection to fail using
>> an invalid charset! So this is a regression of wide support in odbc.
>>
>> Frediano
>> _______________________________________________
>> FreeTDS mailing list
>> [email protected]
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>
>
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>