[freetds] SQLGetData() returns TEXT length minus one on Solaris 64b with SQL Server 2005

Post by Sebastien FLAESCH
Hi all,
$ uname -a
SunOS s64x100 5.10 Generic_120012-14 i86pc i386 i86pc
- freetds-0.92.dev.20120312
- freetds-dev.0.92.377
When fetching a TEXT from the database (SQL Server 2005), using SQL_DATA_AT_EXEC,
it appears that the SQLGetData() function returns the size of the text data,
minus one...
I have tested the same FreeTDS version on a Linux 32b, and SQLGetData() returns
the correct length as expected...

Strange! How do you read the length?

Post by Sebastien FLAESCH
I will continue to investigate, but I wanted to ask if this is a know issue.
When connecting to SQL Server 2008 R2, this does not occur, because SQLGetData()
returns SQL_NO_TOTAL and we fetch text pieces in a different way...

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

Frediano

Sebastien FLAESCH

2013-02-02 17:27:27 UTC

Hi Frediano,

FYI, we use a single-byte encoding (LANG=POSIX) ...

Here is the code we use, nothing particular, this is the same code we
use for different ODBC drivers...

#define BLOB_BLOCK_SIZE 4096
....
static SQLRETURN getBlobPieces(SqlStatement * st, SQLUSMALLINT fpos,
SQLSMALLINT ctype, MyLocator * loc,
FILE * out, SQLLEN * plen)
{
SQLRETURN r = 0;
char buf[BLOB_BLOCK_SIZE];
SQLLEN len;
int i = 0;
while (1) {
r = SQLGetData(st->stmtHandle, fpos, ctype,
(SQLPOINTER) buf, sizeof(buf), &len);
if (!SQL_SUCCEEDED(r) || len == 0 || len == SQL_NULL_DATA)
break;
if (len > (SQLLEN) sizeof(buf) || len == SQL_NO_TOTAL)
len = sizeof(buf);
/* Char data piece get \0, these must be removed! */
if (ctype == SQL_C_CHAR) {
if (buf[len - 1] == '\0') {
len--;
}
}
fwrite(buf, 1, len, out);
}
*plen = len;
return r;
}

Am I missusing SQLGetData()? As you can see, I modify the len after
Does this affect the next call to SQLGetData()?

Anyway, the INITIAL len returned by SQLGetData() is for sure:

(total-bytes - 1)

When using UTF-8, I get SQL_NO_TOTAL in the first call, but in ASCII,
I get the (total size - 1)...

Seb

Strange! How do you read the length?

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

Frediano
_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

Frediano Ziglio

2013-02-03 11:12:42 UTC

Hi,
where is SQL_DATA_AT_EXEC in your code?

Which DM are you using? Is possible that for some reason DM call some
additional function to do some checks. This could discovered enabling
FreeTDS dump.

Quire strange it works correctly on Linux but not on Solaris.
Does data contains no-ASCII characters?
How long are usually these TEXT fields?
Which TDS protocol version are you using?
There is a specific getdata test for this stuff and should work.

Regards,
Frediano

Post by Sebastien FLAESCH
Hi Frediano,
FYI, we use a single-byte encoding (LANG=POSIX) ...
Here is the code we use, nothing particular, this is the same code we
use for different ODBC drivers...
#define BLOB_BLOCK_SIZE 4096
....
static SQLRETURN getBlobPieces(SqlStatement * st, SQLUSMALLINT fpos,
SQLSMALLINT ctype, MyLocator * loc,
FILE * out, SQLLEN * plen)
{
SQLRETURN r = 0;
char buf[BLOB_BLOCK_SIZE];
SQLLEN len;
int i = 0;
while (1) {
r = SQLGetData(st->stmtHandle, fpos, ctype,
(SQLPOINTER) buf, sizeof(buf), &len);
if (!SQL_SUCCEEDED(r) || len == 0 || len == SQL_NULL_DATA)
break;
if (len > (SQLLEN) sizeof(buf) || len == SQL_NO_TOTAL)
len = sizeof(buf);
/* Char data piece get \0, these must be removed! */
if (ctype == SQL_C_CHAR) {
if (buf[len - 1] == '\0') {
len--;
}
}
fwrite(buf, 1, len, out);
}
*plen = len;
return r;
}
Am I missusing SQLGetData()? As you can see, I modify the len after
Does this affect the next call to SQLGetData()?
(total-bytes - 1)
When using UTF-8, I get SQL_NO_TOTAL in the first call, but in ASCII,
I get the (total size - 1)...
Seb

Strange! How do you read the length?

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

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

Sebastien FLAESCH

2013-02-04 10:49:47 UTC

Frediano,

I believe it's related to the client charset conversions...

I did following simple test:

My database collation is CP1252, so to avoid iconv usage, in the ODBC
data source definition, I have now:

ClientCharset = CP1252

The program uses only pure ASCII chars, so this is ok.

Now there is no more iconv error in the log, and the first call to
SQLGetData() returns 10000 bytes as expected...

If fact for character data, ODBC returns the char pieces with an
additional \0 terminator.

So, with a buffer of 4096 bytes:

Call #1 to SQLGetData() returns len=10000 bytes (ok)
Call #2 to SQLGetData() returns len=5905 bytes
there was 5905 bytes left to read, because only 4095 bytes could
be written to the buffer, because of additional \0 terminator.
10000 - 4095 = 5905 ...
Call #3 to SQLGetData() returns len=1810 bytes
5905 - 4095 = 1810 ...
Last call: 1810 bytes fit in the 4096 buffer.

I hope this helps...

Seb

Post by Frediano Ziglio
Hi,
where is SQL_DATA_AT_EXEC in your code?
Which DM are you using? Is possible that for some reason DM call some
additional function to do some checks. This could discovered enabling
FreeTDS dump.
Quire strange it works correctly on Linux but not on Solaris.
Does data contains no-ASCII characters?
How long are usually these TEXT fields?
Which TDS protocol version are you using?
There is a specific getdata test for this stuff and should work.
Regards,
Frediano

Post by Sebastien FLAESCH
Hi Frediano,
FYI, we use a single-byte encoding (LANG=POSIX) ...
Here is the code we use, nothing particular, this is the same code we
use for different ODBC drivers...
#define BLOB_BLOCK_SIZE 4096
....
static SQLRETURN getBlobPieces(SqlStatement * st, SQLUSMALLINT fpos,
SQLSMALLINT ctype, MyLocator * loc,
FILE * out, SQLLEN * plen)
{
SQLRETURN r = 0;
char buf[BLOB_BLOCK_SIZE];
SQLLEN len;
int i = 0;
while (1) {
r = SQLGetData(st->stmtHandle, fpos, ctype,
(SQLPOINTER) buf, sizeof(buf),&len);
if (!SQL_SUCCEEDED(r) || len == 0 || len == SQL_NULL_DATA)
break;
if (len> (SQLLEN) sizeof(buf) || len == SQL_NO_TOTAL)
len = sizeof(buf);
/* Char data piece get \0, these must be removed! */
if (ctype == SQL_C_CHAR) {
if (buf[len - 1] == '\0') {
len--;
}
}
fwrite(buf, 1, len, out);
}
*plen = len;
return r;
}
Am I missusing SQLGetData()? As you can see, I modify the len after
Does this affect the next call to SQLGetData()?
(total-bytes - 1)
When using UTF-8, I get SQL_NO_TOTAL in the first call, but in ASCII,
I get the (total size - 1)...
Seb

Strange! How do you read the length?

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

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

Frediano Ziglio

2013-02-04 17:57:38 UTC

Post by Sebastien FLAESCH
Frediano,
I believe it's related to the client charset conversions...
My database collation is CP1252, so to avoid iconv usage, in the ODBC
ClientCharset = CP1252
The program uses only pure ASCII chars, so this is ok.
Now there is no more iconv error in the log, and the first call to
SQLGetData() returns 10000 bytes as expected...
If fact for character data, ODBC returns the char pieces with an
additional \0 terminator.
Call #1 to SQLGetData() returns len=10000 bytes (ok)
Call #2 to SQLGetData() returns len=5905 bytes
there was 5905 bytes left to read, because only 4095 bytes could
be written to the buffer, because of additional \0 terminator.
10000 - 4095 = 5905 ...
Call #3 to SQLGetData() returns len=1810 bytes
5905 - 4095 = 1810 ...
Last call: 1810 bytes fit in the 4096 buffer.

Well, this is expected. But I don't understand what's going wrong with Solaris.
Could be possible that Solaris do not convert some characters and so
it convert a byte characters to 0 bytes ??
Are you sure that there is only ASCII characters (0-127) ??
Why should Solaris report some warning converting ASCII ??
A dump would be helpful. Send privately to me if it contains sensitive
information.
You could try using libiconv.

Post by Sebastien FLAESCH
I hope this helps...
Seb

Frediano

Post by Sebastien FLAESCH
Hi Frediano,
FYI, we use a single-byte encoding (LANG=POSIX) ...
Here is the code we use, nothing particular, this is the same code we
use for different ODBC drivers...
#define BLOB_BLOCK_SIZE 4096
....
static SQLRETURN getBlobPieces(SqlStatement * st, SQLUSMALLINT fpos,
SQLSMALLINT ctype, MyLocator * loc,
FILE * out, SQLLEN * plen)
{
SQLRETURN r = 0;
char buf[BLOB_BLOCK_SIZE];
SQLLEN len;
int i = 0;
while (1) {
r = SQLGetData(st->stmtHandle, fpos, ctype,
(SQLPOINTER) buf, sizeof(buf),&len);
if (!SQL_SUCCEEDED(r) || len == 0 || len == SQL_NULL_DATA)
break;
if (len> (SQLLEN) sizeof(buf) || len == SQL_NO_TOTAL)
len = sizeof(buf);
/* Char data piece get \0, these must be removed! */
if (ctype == SQL_C_CHAR) {
if (buf[len - 1] == '\0') {
len--;
}
}
fwrite(buf, 1, len, out);
}
*plen = len;
return r;
}
Am I missusing SQLGetData()? As you can see, I modify the len after
Does this affect the next call to SQLGetData()?
(total-bytes - 1)
When using UTF-8, I get SQL_NO_TOTAL in the first call, but in ASCII,
I get the (total size - 1)...
Seb

Strange! How do you read the length?

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

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

Sebastien FLAESCH

2013-02-05 11:46:28 UTC

Well, this is expected. But I don't understand what's going wrong with Solaris.
Could be possible that Solaris do not convert some characters and so
it convert a byte characters to 0 bytes ??

Possible...

Post by Frediano Ziglio
Are you sure that there is only ASCII characters (0-127) ??

Pure ASCII.

Post by Frediano Ziglio
Why should Solaris report some warning converting ASCII ??

My C locale is set to POSIX/C, I don't know why it ends as ISO-8859-1
for the iconv conversions in FreeTDS. Maybe it's the default.

Is there some mapping between the C locale (LANG/LC_ALL) and the iconv
locale name (I know these can be different names, how is this mapped?)

Post by Frediano Ziglio
A dump would be helpful. Send privately to me if it contains sensitive
information.

I send you a dump.

Post by Frediano Ziglio
You could try using libiconv.

We'll try this too.

Post by Sebastien FLAESCH
I hope this helps...
Seb

Frediano

Post by Sebastien FLAESCH
Hi Frediano,
FYI, we use a single-byte encoding (LANG=POSIX) ...
Here is the code we use, nothing particular, this is the same code we
use for different ODBC drivers...
#define BLOB_BLOCK_SIZE 4096
....
static SQLRETURN getBlobPieces(SqlStatement * st, SQLUSMALLINT fpos,
SQLSMALLINT ctype, MyLocator * loc,
FILE * out, SQLLEN * plen)
{
SQLRETURN r = 0;
char buf[BLOB_BLOCK_SIZE];
SQLLEN len;
int i = 0;
while (1) {
r = SQLGetData(st->stmtHandle, fpos, ctype,
(SQLPOINTER) buf, sizeof(buf),&len);
if (!SQL_SUCCEEDED(r) || len == 0 || len == SQL_NULL_DATA)
break;
if (len> (SQLLEN) sizeof(buf) || len == SQL_NO_TOTAL)
len = sizeof(buf);
/* Char data piece get \0, these must be removed! */
if (ctype == SQL_C_CHAR) {
if (buf[len - 1] == '\0') {
len--;
}
}
fwrite(buf, 1, len, out);
}
*plen = len;
return r;
}
Am I missusing SQLGetData()? As you can see, I modify the len after
Does this affect the next call to SQLGetData()?
(total-bytes - 1)
When using UTF-8, I get SQL_NO_TOTAL in the first call, but in ASCII,
I get the (total size - 1)...
Seb

Strange! How do you read the length?

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

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

Sebastien FLAESCH

2013-02-05 14:22:07 UTC

It appears that compiling with libiconv does not help.
Seb

Well, this is expected. But I don't understand what's going wrong with Solaris.
Could be possible that Solaris do not convert some characters and so
it convert a byte characters to 0 bytes ??

Possible...

Post by Frediano Ziglio
Are you sure that there is only ASCII characters (0-127) ??

Pure ASCII.

Post by Frediano Ziglio
Why should Solaris report some warning converting ASCII ??

My C locale is set to POSIX/C, I don't know why it ends as ISO-8859-1
for the iconv conversions in FreeTDS. Maybe it's the default.
Is there some mapping between the C locale (LANG/LC_ALL) and the iconv
locale name (I know these can be different names, how is this mapped?)

Post by Frediano Ziglio
A dump would be helpful. Send privately to me if it contains sensitive
information.

I send you a dump.

Post by Frediano Ziglio
You could try using libiconv.

We'll try this too.

Post by Sebastien FLAESCH
I hope this helps...
Seb

Frediano

Post by Sebastien FLAESCH
Hi Frediano,
FYI, we use a single-byte encoding (LANG=POSIX) ...
Here is the code we use, nothing particular, this is the same code we
use for different ODBC drivers...
#define BLOB_BLOCK_SIZE 4096
....
static SQLRETURN getBlobPieces(SqlStatement * st, SQLUSMALLINT fpos,
SQLSMALLINT ctype, MyLocator * loc,
FILE * out, SQLLEN * plen)
{
SQLRETURN r = 0;
char buf[BLOB_BLOCK_SIZE];
SQLLEN len;
int i = 0;
while (1) {
r = SQLGetData(st->stmtHandle, fpos, ctype,
(SQLPOINTER) buf, sizeof(buf),&len);
if (!SQL_SUCCEEDED(r) || len == 0 || len == SQL_NULL_DATA)
break;
if (len> (SQLLEN) sizeof(buf) || len == SQL_NO_TOTAL)
len = sizeof(buf);
/* Char data piece get \0, these must be removed! */
if (ctype == SQL_C_CHAR) {
if (buf[len - 1] == '\0') {
len--;
}
}
fwrite(buf, 1, len, out);
}
*plen = len;
return r;
}
Am I missusing SQLGetData()? As you can see, I modify the len after
Does this affect the next call to SQLGetData()?
(total-bytes - 1)
When using UTF-8, I get SQL_NO_TOTAL in the first call, but in ASCII,
I get the (total size - 1)...
Seb

Strange! How do you read the length?

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

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

Sebastien FLAESCH

2013-02-06 10:21:35 UTC

FYI:

We have tested with this configure option:

--disable-libiconv

and now it works...

Whatever iconv issue it is, I believe that FreeTDS should check iconv status
and stop with a fatal error if iconv is not able to handle charset conversions.

Character set conversion is critical, when subject of data loss or corruption
with no special warning for the user.

Seb

Post by Sebastien FLAESCH
It appears that compiling with libiconv does not help.
Seb

Well, this is expected. But I don't understand what's going wrong with Solaris.
Could be possible that Solaris do not convert some characters and so
it convert a byte characters to 0 bytes ??

Possible...

Post by Frediano Ziglio
Are you sure that there is only ASCII characters (0-127) ??

Pure ASCII.

Post by Frediano Ziglio
Why should Solaris report some warning converting ASCII ??

My C locale is set to POSIX/C, I don't know why it ends as ISO-8859-1
for the iconv conversions in FreeTDS. Maybe it's the default.
Is there some mapping between the C locale (LANG/LC_ALL) and the iconv
locale name (I know these can be different names, how is this mapped?)

Post by Frediano Ziglio
A dump would be helpful. Send privately to me if it contains sensitive
information.

I send you a dump.

Post by Frediano Ziglio
You could try using libiconv.

We'll try this too.

Post by Sebastien FLAESCH
I hope this helps...
Seb

Frediano

Post by Sebastien FLAESCH
Hi Frediano,
FYI, we use a single-byte encoding (LANG=POSIX) ...
Here is the code we use, nothing particular, this is the same code we
use for different ODBC drivers...
#define BLOB_BLOCK_SIZE 4096
....
static SQLRETURN getBlobPieces(SqlStatement * st, SQLUSMALLINT fpos,
SQLSMALLINT ctype, MyLocator * loc,
FILE * out, SQLLEN * plen)
{
SQLRETURN r = 0;
char buf[BLOB_BLOCK_SIZE];
SQLLEN len;
int i = 0;
while (1) {
r = SQLGetData(st->stmtHandle, fpos, ctype,
(SQLPOINTER) buf, sizeof(buf),&len);
if (!SQL_SUCCEEDED(r) || len == 0 || len == SQL_NULL_DATA)
break;
if (len> (SQLLEN) sizeof(buf) || len == SQL_NO_TOTAL)
len = sizeof(buf);
/* Char data piece get \0, these must be removed! */
if (ctype == SQL_C_CHAR) {
if (buf[len - 1] == '\0') {
len--;
}
}
fwrite(buf, 1, len, out);
}
*plen = len;
return r;
}
Am I missusing SQLGetData()? As you can see, I modify the len after
Does this affect the next call to SQLGetData()?
(total-bytes - 1)
When using UTF-8, I get SQL_NO_TOTAL in the first call, but in ASCII,
I get the (total size - 1)...
Seb

Strange! How do you read the length?

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

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

Frediano Ziglio

2013-02-06 16:18:45 UTC

Post by Sebastien FLAESCH
--disable-libiconv
and now it works...
Whatever iconv issue it is, I believe that FreeTDS should check iconv status
and stop with a fatal error if iconv is not able to handle charset conversions.
Character set conversion is critical, when subject of data loss or corruption
with no special warning for the user.
Seb

Mmm... not that good. It means that Solaris iconv does something that
is not expected by FreeTDS. Probably FreeTDS expect a 1 to 1
conversion while lib iconv provided by Solaris does not respect this.
I should write a test if libiconv linked in is FreeTDS-aware. Probably
using GNU libiconv would fix your issues. However is hard to reproduce
using a libiconv that works as expected.

Frediano

Post by Sebastien FLAESCH
It appears that compiling with libiconv does not help.
Seb

Well, this is expected. But I don't understand what's going wrong with Solaris.
Could be possible that Solaris do not convert some characters and so
it convert a byte characters to 0 bytes ??

Possible...

Post by Frediano Ziglio
Are you sure that there is only ASCII characters (0-127) ??

Pure ASCII.

Post by Frediano Ziglio
Why should Solaris report some warning converting ASCII ??

My C locale is set to POSIX/C, I don't know why it ends as ISO-8859-1
for the iconv conversions in FreeTDS. Maybe it's the default.
Is there some mapping between the C locale (LANG/LC_ALL) and the iconv
locale name (I know these can be different names, how is this mapped?)

Post by Frediano Ziglio
A dump would be helpful. Send privately to me if it contains sensitive
information.

I send you a dump.

Post by Frediano Ziglio
You could try using libiconv.

We'll try this too.

Post by Sebastien FLAESCH
I hope this helps...
Seb

Frediano

Post by Sebastien FLAESCH
Hi Frediano,
FYI, we use a single-byte encoding (LANG=POSIX) ...
Here is the code we use, nothing particular, this is the same code we
use for different ODBC drivers...
#define BLOB_BLOCK_SIZE 4096
....
static SQLRETURN getBlobPieces(SqlStatement * st, SQLUSMALLINT fpos,
SQLSMALLINT ctype, MyLocator * loc,
FILE * out, SQLLEN * plen)
{
SQLRETURN r = 0;
char buf[BLOB_BLOCK_SIZE];
SQLLEN len;
int i = 0;
while (1) {
r = SQLGetData(st->stmtHandle, fpos, ctype,
(SQLPOINTER) buf, sizeof(buf),&len);
if (!SQL_SUCCEEDED(r) || len == 0 || len == SQL_NULL_DATA)
break;
if (len> (SQLLEN) sizeof(buf) || len == SQL_NO_TOTAL)
len = sizeof(buf);
/* Char data piece get \0, these must be removed! */
if (ctype == SQL_C_CHAR) {
if (buf[len - 1] == '\0') {
len--;
}
}
fwrite(buf, 1, len, out);
}
*plen = len;
return r;
}
Am I missusing SQLGetData()? As you can see, I modify the len after
Does this affect the next call to SQLGetData()?
(total-bytes - 1)
When using UTF-8, I get SQL_NO_TOTAL in the first call, but in ASCII,
I get the (total size - 1)...
Seb

Strange! How do you read the length?

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

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

Sebastien FLAESCH

2013-03-14 09:37:20 UTC

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.

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

Post by Sebastien FLAESCH
It appears that compiling with libiconv does not help.
Seb

Well, this is expected. But I don't understand what's going wrong with Solaris.
Could be possible that Solaris do not convert some characters and so
it convert a byte characters to 0 bytes ??

Possible...

Post by Frediano Ziglio
Are you sure that there is only ASCII characters (0-127) ??

Pure ASCII.

Post by Frediano Ziglio
Why should Solaris report some warning converting ASCII ??

My C locale is set to POSIX/C, I don't know why it ends as ISO-8859-1
for the iconv conversions in FreeTDS. Maybe it's the default.
Is there some mapping between the C locale (LANG/LC_ALL) and the iconv
locale name (I know these can be different names, how is this mapped?)

Post by Frediano Ziglio
A dump would be helpful. Send privately to me if it contains sensitive
information.

I send you a dump.

Post by Frediano Ziglio
You could try using libiconv.

We'll try this too.

Post by Sebastien FLAESCH
I hope this helps...
Seb

Frediano

Post by Sebastien FLAESCH
Hi Frediano,
FYI, we use a single-byte encoding (LANG=POSIX) ...
Here is the code we use, nothing particular, this is the same code we
use for different ODBC drivers...
#define BLOB_BLOCK_SIZE 4096
....
static SQLRETURN getBlobPieces(SqlStatement * st, SQLUSMALLINT fpos,
SQLSMALLINT ctype, MyLocator * loc,
FILE * out, SQLLEN * plen)
{
SQLRETURN r = 0;
char buf[BLOB_BLOCK_SIZE];
SQLLEN len;
int i = 0;
while (1) {
r = SQLGetData(st->stmtHandle, fpos, ctype,
(SQLPOINTER) buf, sizeof(buf),&len);
if (!SQL_SUCCEEDED(r) || len == 0 || len == SQL_NULL_DATA)
break;
if (len> (SQLLEN) sizeof(buf) || len == SQL_NO_TOTAL)
len = sizeof(buf);
/* Char data piece get \0, these must be removed! */
if (ctype == SQL_C_CHAR) {
if (buf[len - 1] == '\0') {
len--;
}
}
fwrite(buf, 1, len, out);
}
*plen = len;
return r;
}
Am I missusing SQLGetData()? As you can see, I modify the len after
Does this affect the next call to SQLGetData()?
(total-bytes - 1)
When using UTF-8, I get SQL_NO_TOTAL in the first call, but in ASCII,
I get the (total size - 1)...
Seb

Il giorno 31/gen/2013, alle ore 14:28, Sebastien

Post by Sebastien FLAESCH
Hi all,
$ uname -a
SunOS s64x100 5.10 Generic_120012-14 i86pc i386 i86pc
- freetds-0.92.dev.20120312
- freetds-dev.0.92.377
When fetching a TEXT from the database (SQL Server 2005), using
SQL_DATA_AT_EXEC,
it appears that the SQLGetData() function returns the size of
the text data,
minus one...
I have tested the same FreeTDS version on a Linux 32b, and
SQLGetData() returns
the correct length as expected...

Strange! How do you read the length?

Post by Sebastien FLAESCH
I will continue to investigate, but I wanted to ask if this is
a know issue.
When connecting to SQL Server 2008 R2, this does not occur,
because SQLGetData()
returns SQL_NO_TOTAL and we fetch text pieces in a different way...

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

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

Sebastien FLAESCH

2013-03-14 13:54:19 UTC

Post by Sebastien FLAESCH
Hi,
"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.
This occurs if no ClientCharset is defined in the ODBC data source...
ClientCharset = en_US.8859-15
ClientCharset = en_US.UTF-8

Sorry that was stupid, I mixed locale -l names and iconv -l names ...

In fact SQLGetData() returns a len of zero when

ClientCharset = <invalid_iconv_locale>

In such case the FreeTDS driver should stop with a fatal error.

This is subject of a lot of mistakes and then good luck once you have crap in your db ;-)

Post by Sebastien FLAESCH
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

Post by Sebastien FLAESCH
It appears that compiling with libiconv does not help.
Seb

Well, this is expected. But I don't understand what's going wrong with Solaris.
Could be possible that Solaris do not convert some characters and so
it convert a byte characters to 0 bytes ??

Possible...

Post by Frediano Ziglio
Are you sure that there is only ASCII characters (0-127) ??

Pure ASCII.

Post by Frediano Ziglio
Why should Solaris report some warning converting ASCII ??

My C locale is set to POSIX/C, I don't know why it ends as ISO-8859-1
for the iconv conversions in FreeTDS. Maybe it's the default.
Is there some mapping between the C locale (LANG/LC_ALL) and the iconv
locale name (I know these can be different names, how is this mapped?)

Post by Frediano Ziglio
A dump would be helpful. Send privately to me if it contains sensitive
information.

I send you a dump.

Post by Frediano Ziglio
You could try using libiconv.

We'll try this too.

Post by Sebastien FLAESCH
I hope this helps...
Seb

Frediano

Post by Sebastien FLAESCH
Hi Frediano,
FYI, we use a single-byte encoding (LANG=POSIX) ...
Here is the code we use, nothing particular, this is the same code we
use for different ODBC drivers...
#define BLOB_BLOCK_SIZE 4096
....
static SQLRETURN getBlobPieces(SqlStatement * st, SQLUSMALLINT fpos,
SQLSMALLINT ctype, MyLocator * loc,
FILE * out, SQLLEN * plen)
{
SQLRETURN r = 0;
char buf[BLOB_BLOCK_SIZE];
SQLLEN len;
int i = 0;
while (1) {
r = SQLGetData(st->stmtHandle, fpos, ctype,
(SQLPOINTER) buf, sizeof(buf),&len);
if (!SQL_SUCCEEDED(r) || len == 0 || len == SQL_NULL_DATA)
break;
if (len> (SQLLEN) sizeof(buf) || len == SQL_NO_TOTAL)
len = sizeof(buf);
/* Char data piece get \0, these must be removed! */
if (ctype == SQL_C_CHAR) {
if (buf[len - 1] == '\0') {
len--;
}
}
fwrite(buf, 1, len, out);
}
*plen = len;
return r;
}
Am I missusing SQLGetData()? As you can see, I modify the len after
Does this affect the next call to SQLGetData()?
(total-bytes - 1)
When using UTF-8, I get SQL_NO_TOTAL in the first call, but in ASCII,
I get the (total size - 1)...
Seb

Il giorno 31/gen/2013, alle ore 14:28, Sebastien

Post by Sebastien FLAESCH
Hi all,
$ uname -a
SunOS s64x100 5.10 Generic_120012-14 i86pc i386 i86pc
- freetds-0.92.dev.20120312
- freetds-dev.0.92.377
When fetching a TEXT from the database (SQL Server 2005), using
SQL_DATA_AT_EXEC,
it appears that the SQLGetData() function returns the size of
the text data,
minus one...
I have tested the same FreeTDS version on a Linux 32b, and
SQLGetData() returns
the correct length as expected...

Strange! How do you read the length?

Post by Sebastien FLAESCH
I will continue to investigate, but I wanted to ask if this is
a know issue.
When connecting to SQL Server 2008 R2, this does not occur,
because SQLGetData()
returns SQL_NO_TOTAL and we fetch text pieces in a different way...

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

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

Frediano Ziglio

2013-03-15 11:23:28 UTC

Post by Sebastien FLAESCH
Hi,
"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.

Fixed recently on master branch (don't ask me the version). Commits were

http://gitorious.org/freetds/freetds/commit/f3bb4ca07490b3e1d32266223b571ef6da588c9c
and
http://gitorious.org/freetds/freetds/commit/a3b9c0307a62e2a6fb1a16ba5760081820cadbe5

Post by Sebastien FLAESCH
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.
This occurs if no ClientCharset is defined in the ODBC data source...
ClientCharset = en_US.8859-15
ClientCharset = en_US.UTF-8
The len returned by SQLGetData() is zero, as expected.
Some news about this?

I'll add a test for this case.

Post by Sebastien FLAESCH
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

Yes, you are right. Probably the better thinks is to make the
connection fails with a proper error.

Frediano

Post by Sebastien FLAESCH
It appears that compiling with libiconv does not help.
Seb

Well, this is expected. But I don't understand what's going wrong with Solaris.
Could be possible that Solaris do not convert some characters and so
it convert a byte characters to 0 bytes ??

Possible...

Post by Frediano Ziglio
Are you sure that there is only ASCII characters (0-127) ??

Pure ASCII.

Post by Frediano Ziglio
Why should Solaris report some warning converting ASCII ??

My C locale is set to POSIX/C, I don't know why it ends as ISO-8859-1
for the iconv conversions in FreeTDS. Maybe it's the default.
Is there some mapping between the C locale (LANG/LC_ALL) and the iconv
locale name (I know these can be different names, how is this mapped?)

Post by Frediano Ziglio
A dump would be helpful. Send privately to me if it contains sensitive
information.

I send you a dump.

Post by Frediano Ziglio
You could try using libiconv.

We'll try this too.

Post by Sebastien FLAESCH
I hope this helps...
Seb

Frediano

Post by Sebastien FLAESCH
Hi Frediano,
FYI, we use a single-byte encoding (LANG=POSIX) ...
Here is the code we use, nothing particular, this is the same code we
use for different ODBC drivers...
#define BLOB_BLOCK_SIZE 4096
....
static SQLRETURN getBlobPieces(SqlStatement * st, SQLUSMALLINT fpos,
SQLSMALLINT ctype, MyLocator * loc,
FILE * out, SQLLEN * plen)
{
SQLRETURN r = 0;
char buf[BLOB_BLOCK_SIZE];
SQLLEN len;
int i = 0;
while (1) {
r = SQLGetData(st->stmtHandle, fpos, ctype,
(SQLPOINTER) buf, sizeof(buf),&len);
if (!SQL_SUCCEEDED(r) || len == 0 || len == SQL_NULL_DATA)
break;
if (len> (SQLLEN) sizeof(buf) || len == SQL_NO_TOTAL)
len = sizeof(buf);
/* Char data piece get \0, these must be removed! */
if (ctype == SQL_C_CHAR) {
if (buf[len - 1] == '\0') {
len--;
}
}
fwrite(buf, 1, len, out);
}
*plen = len;
return r;
}
Am I missusing SQLGetData()? As you can see, I modify the len after
Does this affect the next call to SQLGetData()?
(total-bytes - 1)
When using UTF-8, I get SQL_NO_TOTAL in the first call, but in ASCII,
I get the (total size - 1)...
Seb

Il giorno 31/gen/2013, alle ore 14:28, Sebastien

Post by Sebastien FLAESCH
Hi all,
$ uname -a
SunOS s64x100 5.10 Generic_120012-14 i86pc i386 i86pc
- freetds-0.92.dev.20120312
- freetds-dev.0.92.377
When fetching a TEXT from the database (SQL Server 2005), using
SQL_DATA_AT_EXEC,
it appears that the SQLGetData() function returns the size of
the text data,
minus one...
I have tested the same FreeTDS version on a Linux 32b, and
SQLGetData() returns
the correct length as expected...

Strange! How do you read the length?

Post by Sebastien FLAESCH
I will continue to investigate, but I wanted to ask if this is
a know issue.
When connecting to SQL Server 2008 R2, this does not occur,
because SQLGetData()
returns SQL_NO_TOTAL and we fetch text pieces in a different way...

This is done to deal with different encodings.

Post by Sebastien FLAESCH
Thanks
Seb

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

Frediano Ziglio

2013-03-16 14:04:53 UTC

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?

Post by Sebastien FLAESCH
This occurs if no ClientCharset is defined in the ODBC data source...
ClientCharset = en_US.8859-15
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

Sebastien FLAESCH

2013-03-18 09:04:42 UTC

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

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

Sebastien FLAESCH

2013-03-18 09:25:43 UTC

Sorry:

After a closer look I don't use column-wise binding if a text/byte
column is in the result set.

Seb

Post by Sebastien FLAESCH
OK.
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

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

Sebastien FLAESCH

2013-03-18 09:50:19 UTC

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

ODBC source:

[ftm_msvtest1_cobra]
Description = SQL Server 2012
Trace = No
Server = cobra
Database = msvtest1
Port = 1680
TDS_Version = 8.0

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

Post by Sebastien FLAESCH
After a closer look I don't use column-wise binding if a text/byte
column is in the result set.
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: odbctest2.c
Type: text/x-csrc
Size: 7082 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/freetds/attachments/20130318/0bbc0716/attachment-0001.bin

Frediano Ziglio

2013-03-18 22:35:18 UTC

Have you tried this with a newer FreeTDS version ??

It works for me. Unexpectedly it returns data even after a
SQLMoreResults. Did you try with MS drivers?

Frediano

Post by Sebastien FLAESCH
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.
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.

Post by Sebastien FLAESCH
[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.

Post by Sebastien FLAESCH
num cols: 2
fetch 1: rows fetched = 1
get data 1: len = 0
num cols: 2
fetch 1: rows fetched = 1
get data 1: len = 4095
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

Post by Sebastien FLAESCH
After a closer look I don't use column-wise binding if a text/byte
column is in the result set.
Seb

Post by Sebastien FLAESCH
Hi,
I have already reported an issue regarding SQLGetData()/iconv, see
"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.

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

Sebastien FLAESCH

2013-03-19 09:04:22 UTC

Post by Frediano Ziglio
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

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Frediano

I think you keep 0.83 for compatibility.

Post by Sebastien FLAESCH
[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.

Post by Sebastien FLAESCH
After a closer look I don't use column-wise binding if a text/byte
column is in the result set.
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

Frediano Ziglio

2013-03-19 09:32:22 UTC

Probably is broken the link creation, I never noted the problem.
However loot at ftp://ftp.freetds.org/pub/freetds/current/

Frediano

Post by Frediano Ziglio
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

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Frediano

I think you keep 0.83 for compatibility.

Post by Sebastien FLAESCH
[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.

Post by Sebastien FLAESCH
After a closer look I don't use column-wise binding if a text/byte
column is in the result set.
Seb

Post by Sebastien FLAESCH
Hi,
I have already reported an issue regarding SQLGetData()/iconv, see
"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.

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

Sebastien FLAESCH

2013-03-19 10:47:31 UTC

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

Post by Frediano Ziglio
Probably is broken the link creation, I never noted the problem.
However loot at ftp://ftp.freetds.org/pub/freetds/current/
Frediano

Post by Frediano Ziglio
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

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Frediano

I think you keep 0.83 for compatibility.

Post by Sebastien FLAESCH
[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.

Post by Sebastien FLAESCH
After a closer look I don't use column-wise binding if a text/byte
column is in the result set.
Seb

Post by Sebastien FLAESCH
OK.
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

Post by Sebastien FLAESCH
Hi,
I have already reported an issue regarding SQLGetData()/iconv, see
"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.

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

Frediano Ziglio

2013-03-19 11:10:02 UTC

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

Post by Sebastien FLAESCH
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

Post by Frediano Ziglio
Probably is broken the link creation, I never noted the problem.
However loot at ftp://ftp.freetds.org/pub/freetds/current/
Frediano

Post by Frediano Ziglio
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

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Frediano

I think you keep 0.83 for compatibility.

Post by Sebastien FLAESCH
[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.

Post by Sebastien FLAESCH
After a closer look I don't use column-wise binding if a text/byte
column is in the result set.
Seb

Post by Sebastien FLAESCH
OK.
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

Post by Sebastien FLAESCH
Hi,
I have already reported an issue regarding SQLGetData()/iconv, see
"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.

Post by Sebastien FLAESCH
This occurs if no ClientCharset is defined in the ODBC data source...
ClientCharset = en_US.8859-15
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

Sebastien FLAESCH

2013-03-19 11:28:55 UTC

Sorry I mixed "current" and "dev" version.
I will try 0.92.549.
Seb

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Probably is broken the link creation, I never noted the problem.
However loot at ftp://ftp.freetds.org/pub/freetds/current/
Frediano

Post by Frediano Ziglio
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

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Frediano

I think you keep 0.83 for compatibility.

Post by Sebastien FLAESCH
[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.

Post by Sebastien FLAESCH
After a closer look I don't use column-wise binding if a text/byte
column is in the result set.
Seb

Post by Sebastien FLAESCH
OK.
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

Post by Sebastien FLAESCH
Hi,
I have already reported an issue regarding SQLGetData()/iconv, see
"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.

Post by Sebastien FLAESCH
This occurs if no ClientCharset is defined in the ODBC data source...
ClientCharset = en_US.8859-15
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

Sebastien FLAESCH

2013-03-19 12:21:19 UTC

I still have the same problem with the version 0.92.549:

$ 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

$ file odbctest2.bin
odbctest2.bin: 64-bit XCOFF executable or object module not stripped

$ echo $LIBPATH
/dbs/64bits/tds/0.92.549/lib

$ slibclean

$ ./odbctest2.bin
num cols: 2
fetch 1: rows fetched = 1
get data 1: len = 4095

Seb

Post by Sebastien FLAESCH
Sorry I mixed "current" and "dev" version.
I will try 0.92.549.
Seb

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Probably is broken the link creation, I never noted the problem.
However loot at ftp://ftp.freetds.org/pub/freetds/current/
Frediano

Post by Frediano Ziglio
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

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Frediano

I think you keep 0.83 for compatibility.

Post by Sebastien FLAESCH
[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.

Post by Sebastien FLAESCH
After a closer look I don't use column-wise binding if a text/byte
column is in the result set.
Seb

Post by Sebastien FLAESCH
OK.
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

Post by Sebastien FLAESCH
Hi,
I have already reported an issue regarding SQLGetData()/iconv, see
"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.

Post by Sebastien FLAESCH
This occurs if no ClientCharset is defined in the ODBC data source...
ClientCharset = en_US.8859-15
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

Frediano Ziglio

2013-03-20 17:28:18 UTC

Post by Sebastien FLAESCH
$ 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

0.83 ??

Post by Sebastien FLAESCH
$ file odbctest2.bin
odbctest2.bin: 64-bit XCOFF executable or object module not stripped
$ echo $LIBPATH
/dbs/64bits/tds/0.92.549/lib

Is this used to override libraries ?

Post by Sebastien FLAESCH
$ slibclean
$ ./odbctest2.bin
num cols: 2
fetch 1: rows fetched = 1
get data 1: len = 4095
Seb

Mmm... could I have access (I don't need root) to a machine?

Frediano

Post by Sebastien FLAESCH
Sorry I mixed "current" and "dev" version.
I will try 0.92.549.
Seb

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Probably is broken the link creation, I never noted the problem.
However loot at ftp://ftp.freetds.org/pub/freetds/current/
Frediano

Post by Frediano Ziglio
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

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Frediano

I think you keep 0.83 for compatibility.

Post by Sebastien FLAESCH
[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.

Post by Sebastien FLAESCH
After a closer look I don't use column-wise binding if a text/byte
column is in the result set.
Seb

Post by Sebastien FLAESCH
OK.
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

Post by Sebastien FLAESCH
Hi,
I have already reported an issue regarding SQLGetData()/iconv, see
"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.

Post by Sebastien FLAESCH
This occurs if no ClientCharset is defined in the ODBC data source...
ClientCharset = en_US.8859-15
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

Sebastien FLAESCH

2013-03-20 17:45:22 UTC

Oups! my mistake in the link options, but it does not fix it:

comp at zebulon:/tmp$ cat comp.sh
xlc -O2 -qmaxmem=8192 -q64 \
-I/dbs/64bits/uxo/2.3.1/include\
-o odbctest2.bin odbctest2.c\
-L/dbs/64bits/tds/0.92.549/lib -ltdsodbc

comp at zebulon:/tmp$ sh comp.sh

comp at zebulon:/tmp$ export LIBPATH=/dbs/64bits/tds/0.92.549/lib
(like LD_LIBRARY_PATH, to overwrite lib path used at link time)

comp at zebulon:/tmp$ slibclean
(unloads shared libs from memory to be sure)

comp at zebulon:/tmp$ ./odbctest2.bin
num cols: 2
fetch 1: rows fetched = 1
get data 1: len = 4095

comp at zebulon:/tmp$ dump -X64 -H ./odbctest2.bin

./odbctest2.bin:

***Loader Section***
Loader Header Information
VERSION# #SYMtableENT #RELOCent LENidSTR
0x00000001 0x00000019 0x00000023 0x00000069

#IMPfilID OFFidSTR LENstrTBL OFFstrTBL
0x00000003 0x000004c0 0x00000169 0x00000529

***Import File Strings***
INDEX PATH BASE MEMBER
0 /dbs/64bits/tds/0.92.549/lib:/usr/vac/lib:/usr/lib:/lib
1 libc.a shr_64.o
2 libtdsodbc.a libtdsodbc.so.0

Post by Sebastien FLAESCH
$ 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

0.83 ??

Post by Sebastien FLAESCH
$ file odbctest2.bin
odbctest2.bin: 64-bit XCOFF executable or object module not stripped
$ echo $LIBPATH
/dbs/64bits/tds/0.92.549/lib

Is this used to override libraries ?

Post by Sebastien FLAESCH
$ slibclean
$ ./odbctest2.bin
num cols: 2
fetch 1: rows fetched = 1
get data 1: len = 4095
Seb

Mmm... could I have access (I don't need root) to a machine?
Frediano

Post by Sebastien FLAESCH
Sorry I mixed "current" and "dev" version.
I will try 0.92.549.
Seb

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Probably is broken the link creation, I never noted the problem.
However loot at ftp://ftp.freetds.org/pub/freetds/current/
Frediano

Post by Frediano Ziglio
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

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Frediano

I think you keep 0.83 for compatibility.

Post by Sebastien FLAESCH
[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.

Post by Sebastien FLAESCH
After a closer look I don't use column-wise binding if a text/byte
column is in the result set.
Seb

Post by Sebastien FLAESCH
OK.
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

Post by Sebastien FLAESCH
Hi,
I have already reported an issue regarding SQLGetData()/iconv, see
"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.

Post by Sebastien FLAESCH
This occurs if no ClientCharset is defined in the ODBC data source...
ClientCharset = en_US.8859-15
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

Frediano Ziglio

2013-03-30 15:24:25 UTC

Can I have access to one of the AIX machines ??

I'm currently on holidays, I'll be back on Thursday.

Frediano

Post by Sebastien FLAESCH
comp at zebulon:/tmp$ cat comp.sh
xlc -O2 -qmaxmem=8192 -q64 \
-I/dbs/64bits/uxo/2.3.1/include\
-o odbctest2.bin odbctest2.c\
-L/dbs/64bits/tds/0.92.549/lib -ltdsodbc
comp at zebulon:/tmp$ sh comp.sh
comp at zebulon:/tmp$ export LIBPATH=/dbs/64bits/tds/0.92.549/lib
(like LD_LIBRARY_PATH, to overwrite lib path used at link time)
comp at zebulon:/tmp$ slibclean
(unloads shared libs from memory to be sure)
comp at zebulon:/tmp$ ./odbctest2.bin
num cols: 2
fetch 1: rows fetched = 1
get data 1: len = 4095
comp at zebulon:/tmp$ dump -X64 -H ./odbctest2.bin
***Loader Section***
Loader Header Information
VERSION# #SYMtableENT #RELOCent LENidSTR
0x00000001 0x00000019 0x00000023 0x00000069
#IMPfilID OFFidSTR LENstrTBL OFFstrTBL
0x00000003 0x000004c0 0x00000169 0x00000529
***Import File Strings***
INDEX PATH BASE MEMBER
0 /dbs/64bits/tds/0.92.549/lib:/usr/vac/lib:/usr/lib:/lib
1 libc.a shr_64.o
2 libtdsodbc.a libtdsodbc.so.0

Post by Sebastien FLAESCH
$ 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

0.83 ??

Post by Sebastien FLAESCH
$ file odbctest2.bin
odbctest2.bin: 64-bit XCOFF executable or object module not stripped
$ echo $LIBPATH
/dbs/64bits/tds/0.92.549/lib

Is this used to override libraries ?

Post by Sebastien FLAESCH
$ slibclean
$ ./odbctest2.bin
num cols: 2
fetch 1: rows fetched = 1
get data 1: len = 4095
Seb

Mmm... could I have access (I don't need root) to a machine?
Frediano

Post by Sebastien FLAESCH
Sorry I mixed "current" and "dev" version.
I will try 0.92.549.
Seb

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Probably is broken the link creation, I never noted the problem.
However loot at ftp://ftp.freetds.org/pub/freetds/current/
Frediano

Post by Frediano Ziglio
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

Post by Frediano Ziglio
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

Post by Frediano Ziglio
Frediano

I think you keep 0.83 for compatibility.

Post by Sebastien FLAESCH
[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.

Post by Sebastien FLAESCH
After a closer look I don't use column-wise binding if a text/byte
column is in the result set.
Seb

Post by Sebastien FLAESCH
OK.
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

Post by Sebastien FLAESCH
Hi,
I have already reported an issue regarding SQLGetData()/iconv, see
"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.

Post by Sebastien FLAESCH
This occurs if no ClientCharset is defined in the ODBC data source...
ClientCharset = en_US.8859-15
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

Sebastien FLAESCH

2013-04-02 12:18:36 UTC

Ok thanks.
We'll setup one of our AIX machines to give you access.
Seb

Post by Frediano Ziglio
Can I have access to one of the AIX machines ??
I'm currently on holidays, I'll be back on Thursday.
Frediano

Frediano Ziglio

2013-04-04 18:43:49 UTC

Found!

Actually the problem is in iconv AIX implementation, iconv is a function
like

size_t iconv(iconv_t cd,
char **inbuf, size_t *inbytesleft,
char **outbuf, size_t *outbytesleft);

if *inbuf is NULL and *inbytesleft is 0 AIX threat input as an infinite
buffer with zeroes so it convert an empty string (cause for libTDS view is
an empty string) to a set of zeroes (actually up to the output buffer which
is 4095 if you take into account space for terminator).

The simpler fix is to test and assume empty string if *inbytesleft == 0 in
tds_iconv.

Frediano

2013/4/2 Sebastien FLAESCH <sf at 4js.com>

Post by Sebastien FLAESCH
Ok thanks.
We'll setup one of our AIX machines to give you access.
Seb

Post by Frediano Ziglio
Can I have access to one of the AIX machines ??
I'm currently on holidays, I'll be back on Thursday.
Frediano

_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

Frediano Ziglio

2013-04-04 20:21:15 UTC

Fix in git repository. Also fixed problem with AIX and SQLPutData with 0
bytes.

Frediano

2013/4/4 Frediano Ziglio <freddy77 at gmail.com>

Post by Frediano Ziglio
Found!
Actually the problem is in iconv AIX implementation, iconv is a function
like
size_t iconv(iconv_t cd,
char **inbuf, size_t *inbytesleft,
char **outbuf, size_t *outbytesleft);
if *inbuf is NULL and *inbytesleft is 0 AIX threat input as an infinite
buffer with zeroes so it convert an empty string (cause for libTDS view is
an empty string) to a set of zeroes (actually up to the output buffer which
is 4095 if you take into account space for terminator).
The simpler fix is to test and assume empty string if *inbytesleft == 0 in
tds_iconv.
Frediano
2013/4/2 Sebastien FLAESCH <sf at 4js.com>

Post by Sebastien FLAESCH
Ok thanks.
We'll setup one of our AIX machines to give you access.
Seb

Post by Frediano Ziglio
Can I have access to one of the AIX machines ??
I'm currently on holidays, I'll be back on Thursday.
Frediano

_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

Sebastien FLAESCH

2013-04-05 06:57:47 UTC

Great!

I will test the last version...

Keep in mind my remark about invalid iconv names. During my tests, I saw
that an invalid ClientCharset value was just ignored. By mistake I used
a system locale (LANG/LC_ALL) name instead of an iconv charset name...

If iconv cannot initialize properly, freetds lib should stop with an error.

Seb

Post by Frediano Ziglio
Fix in git repository. Also fixed problem with AIX and SQLPutData with 0
bytes.
Frediano
2013/4/4 Frediano Ziglio<freddy77 at gmail.com>

Post by Sebastien FLAESCH
Ok thanks.
We'll setup one of our AIX machines to give you access.
Seb

Post by Frediano Ziglio
Can I have access to one of the AIX machines ??
I'm currently on holidays, I'll be back on Thursday.
Frediano

_______________________________________________
FreeTDS mailing list
FreeTDS at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

Sebastien FLAESCH

2013-04-05 07:09:47 UTC