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

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
>