Heikki wrote:
> I'm afraid I can't easily compile and execute that either, with all the
Windows-ism's in it. Could you pick one of the regression test cases (e.g
http://git.postgresql.org/gitweb/?p=psqlodbc.git;a=blob_plain;f=test/src/sel
ect-test.c;hb=HEAD),
> and modify it to reproduce the problem? And please also include the SQL
statements to create the test table and data.
Ok, I included a little create script, and modified one of the regression
test files to fetch a single text value as WCHAR from a single row of data.
The resulting program is reasonably simple.
The end of the output with version 9.2.1 of the driver looks like this:
$computedZiffer = 10 - ($sum % 10)
if ($computedZiffer -eq $pruefZiffer) { $ret = $true }
}
$ret
strlen = 487
sqlLen = 974
disconnecting
Press ENTER to exit...
And here it is with 9.3.1:
$computedZiffer = 10 - ($sum % 10)
if ($computedZiffer -eq $pruefZiffer) { $ret = $true }
}
$ret
strlen = 459
sqlLen = 974
disconnecting
Press ENTER to exit...
strlen is different in both cases, but sqlLen is the same. I modified the
program to output the received SQL_C_WCHAR value in binary (preceded by a
UTF16 BOM). The two result files are attached (value921.txt and
value931.txt). If you look at them in a hex editor, you will notice that the
9.2.1 version contains some Ctrl-M characters! Apparently, these have been
stripped in the 9.3.1 version, but the sqlLen value is still the same. I
suppose that .NET uses the latter value to determine how many characters to
include in its query result string (null characters are perfectly normal
characters in C# strings).
Regards,
--
Nils Gösche
Dont ask for whom the <Ctrl-G> tolls.