Skip to Content.
Sympa Menu

freetds - Re: [freetds] SQLGetData() returns len 4095 for empty TEXT on AIX 6.1 without ClientCharset defined

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Re: [freetds] SQLGetData() returns len 4095 for empty TEXT on AIX 6.1 without ClientCharset defined

Chronological Thread  
    < Chronological >       < Thread >
  • From: Sebastien FLAESCH <sf AT 4js.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] SQLGetData() returns len 4095 for empty TEXT on AIX 6.1 without ClientCharset defined
  • Date: Tue, 19 Mar 2013 12:28:55 +0100
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




Archive powered by MHonArc 2.6.24.

Top of Page