Re: SQLGetData() returns len 4095 for empty TEXT on AIX 6.1 without ClientCharset defined
Frediano Ziglio <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <CAHt6W4fd5L-tKGJLUfi0Rx_MGqnt_1sGRM=AgPjm4btsO+Xnvg@mail.gmail.com> |
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