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

I still have the same problem with the version 0.92.549:

$ 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

$ file odbctest2.bin
odbctest2.bin: 64-bit XCOFF executable or object module not stripped

$ echo $LIBPATH
/dbs/64bits/tds/0.92.549/lib

$ slibclean

$ ./odbctest2.bin
num cols: 2
fetch 1: rows fetched = 1
get data 1: len = 4095


Seb

On 03/19/2013 12:28 PM, Sebastien FLAESCH wrote:
> Sorry I mixed "current" and "dev" version.
> I will try 0.92.549.
> Seb
>
> On 03/19/2013 12:10 PM, Frediano Ziglio wrote:
>> Last version in the directory is 0.92.549.
>>
>> I downloaded the file and checked that configure.ac, configure and
>> freetds.spec contains the correct version and it's ok.
>>
>> Frediano
>>
>> 2013/3/19 Sebastien FLAESCH<[email protected]>:
>>> Thank you Frediano.
>>>
>>> I am already using version 0.92.377!  Are there changes committed
>>> and are sources published, without increasing the version number?
>>>
>>> What AIX version are you using? We have an AIX 6.1...
>>>
>>> Seb
>>>
>>> On 03/19/2013 10:32 AM, Frediano Ziglio wrote:
>>>> Probably is broken the link creation, I never noted the problem.
>>>> However loot at ftp://ftp.freetds.org/pub/freetds/current/
>>>>
>>>> Frediano
>>>>
>>>> 2013/3/19 Sebastien FLAESCH<[email protected]>:
>>>>> 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
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> FreeTDS mailing list
>>>>> [email protected]
>>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>> _______________________________________________
>>>> FreeTDS mailing list
>>>> [email protected]
>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>>
>>>
>>> _______________________________________________
>>> FreeTDS mailing list
>>> [email protected]
>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>> _______________________________________________
>> FreeTDS mailing list
>> [email protected]
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>
>
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>