FreeTDS Development Group

[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