Re: SQLGetData() returns len 4095 for empty TEXT on AIX 6.1 without ClientCharset defined
Sebastien FLAESCH <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Organization | Four Js Development Tools |
| Message-ID | <[email protected]> |
Oups! my mistake in the link options, but it does not fix it:
comp@zebulon:/tmp$ cat comp.sh
xlc -O2 -qmaxmem=8192 -q64 \
-I/dbs/64bits/uxo/2.3.1/include\
-o odbctest2.bin odbctest2.c\
-L/dbs/64bits/tds/0.92.549/lib -ltdsodbc
comp@zebulon:/tmp$ sh comp.sh
comp@zebulon:/tmp$ export LIBPATH=/dbs/64bits/tds/0.92.549/lib
(like LD_LIBRARY_PATH, to overwrite lib path used at link time)
comp@zebulon:/tmp$ slibclean
(unloads shared libs from memory to be sure)
comp@zebulon:/tmp$ ./odbctest2.bin
num cols: 2
fetch 1: rows fetched = 1
get data 1: len = 4095
comp@zebulon:/tmp$ dump -X64 -H ./odbctest2.bin
./odbctest2.bin:
***Loader Section***
Loader Header Information
VERSION# #SYMtableENT #RELOCent LENidSTR
0x00000001 0x00000019 0x00000023 0x00000069
#IMPfilID OFFidSTR LENstrTBL OFFstrTBL
0x00000003 0x000004c0 0x00000169 0x00000529
***Import File Strings***
INDEX PATH BASE MEMBER
0 /dbs/64bits/tds/0.92.549/lib:/usr/vac/lib:/usr/lib:/lib
1 libc.a shr_64.o
2 libtdsodbc.a libtdsodbc.so.0
On 03/20/2013 06:28 PM, Frediano Ziglio wrote:
> 2013/3/19 Sebastien FLAESCH<[email protected]>:
>> 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
>>
>
> 0.83 ??
>
>> $ file odbctest2.bin
>> odbctest2.bin: 64-bit XCOFF executable or object module not stripped
>>
>> $ echo $LIBPATH
>> /dbs/64bits/tds/0.92.549/lib
>>
>
> Is this used to override libraries ?
>
>> $ slibclean
>>
>> $ ./odbctest2.bin
>> num cols: 2
>> fetch 1: rows fetched = 1
>> get data 1: len = 4095
>>
>>
>> Seb
>>
>
> Mmm... could I have access (I don't need root) to a machine?
>
> Frediano
>
>> 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
>>>
>>
>> _______________________________________________
>> FreeTDS mailing list
>> [email protected]
>> http://lists.ibiblio.org/mailman/listinfo/freetds
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>