FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

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