FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2013/3/19 Sebastien FLAESCH <sf AT 4js.com>:
> 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<sf AT 4js.com>:
>>>> 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<sf AT 4js.com>:
>>>>>> 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<sf AT 4js.com>:
>>>>>>>> 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<sf AT 4js.com>:
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>> FreeTDS AT lists.ibiblio.org
>>>>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> FreeTDS mailing list
>>>>>> FreeTDS AT lists.ibiblio.org
>>>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>>> _______________________________________________
>>>>> FreeTDS mailing list
>>>>> FreeTDS AT lists.ibiblio.org
>>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>>>
>>>>
>>>> _______________________________________________
>>>> FreeTDS mailing list
>>>> FreeTDS AT lists.ibiblio.org
>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>> _______________________________________________
>>> FreeTDS mailing list
>>> FreeTDS AT lists.ibiblio.org
>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>
>>
>> _______________________________________________
>> FreeTDS mailing list
>> FreeTDS AT lists.ibiblio.org
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds