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

2013/3/14 Sebastien FLAESCH <[email protected]>:
> 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