FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

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