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

Chronological Thread  
  • From: Sebastien FLAESCH <sf AT 4js.com>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] SQLGetData() returns len 4095 for empty TEXT on AIX 6.1 without ClientCharset defined
  • Date: Mon, 18 Mar 2013 10:04:42 +0100

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






Archive powered by MHonArc 2.6.24.

Top of Page