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

On 03/18/2013 11:35 PM, Frediano Ziglio wrote:
> Have you tried this with a newer FreeTDS version ??

What is the the version number of the "newer version?
Where can I get it?
Here?
ftp://ftp.freetds.org/pub/freetds/current/freetds-current.tgz

> It works for me. Unexpectedly it returns data even after a
> SQLMoreResults. Did you try with MS drivers?

I did not try the little sample I have sent, but I use the same
code with SQL Native Client, with the same regression test, and
I get the expected length of zero.

Tx
Seb

> Frediano
>
>
> 2013/3/18 Sebastien FLAESCH<[email protected]>:
>> Ok, once again ;-)
>>
>> Attached the little sample to reproduce.
>>
>> I fact, I use column-wise binding, but when LOB columns need to be
>> fetched, I use an array size of 1. It may look strange, but I have
>> to write generic code, to execute SQL statements that are not known
>> at compile time.
>>
>> Compilation command used:
>>
>> xlc -O2 -qmaxmem=8192 -q64 -I/dbs/64bits/uxo/2.3.1/include
>>      -o odbctest2.bin odbctest2.c
>>      -L/dbs/64bits/tds/0.83/lib -ltdsodbc
>>
>
> I think you keep 0.83 for compatibility.
>
>>
>> ODBC source:
>>
>> [ftm_msvtest1_cobra]
>> Description     = SQL Server 2012
>> Trace           = No
>> Server          = cobra
>> Database        = msvtest1
>> Port            = 1680
>> TDS_Version     = 8.0
>>
>
> You can use 7.1 here.
>
>>
>>
>> Output on the Linux 32b machine:
>>
>> num cols: 2
>> fetch 1: rows fetched = 1
>> get data 1: len = 0
>>
>> Output on the AIX 6.1 machine:
>>
>> num cols: 2
>> fetch 1: rows fetched = 1
>> get data 1: len = 4095
>>
>>
>> Maybe this can help:
>>
>> When I set a (valid) ClientCharset like ISO8859-15 or UTF-8, I get the
>> unexpected length of 4095, but with an invalid ClientCharset, I get zero.
>>
>> !!! The length returned by SQLGetData() is in fact the size of the buffer
>> provided, minus one...
>>
>>
>> (sorry for the confusion)
>> Seb
>>
>>
>>
>> On 03/18/2013 10:25 AM, Sebastien FLAESCH wrote:
>>>
>>> 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
>