You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@xalan.apache.org by bu...@apache.org on 2004/02/05 20:24:58 UTC

DO NOT REPLY [Bug 11788] - Basic-Connection SQL Extension Sample Failed If data column is defined as data type nvarchar

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11788>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11788

Basic-Connection SQL Extension Sample Failed If data column is defined as data type nvarchar

johnglinux@eyecatching.com changed:

------- Additional Comments From johnglinux@eyecatching.com 2004-02-05 19:24 -------
This bug seemed to be a JDBC driver bug but was never proven.
Recently I downloaded the latest version of the MSSQL JDBC
drivers and it seems now that all queries submitted to the
server have nvarchar support added in .

While I have not tested this bug specifically, I recently found
another bug that was had nvarchar implications. Specifically, if
you set precision (which the SQL extension is doing since 2.5.1)
and you update a (n)varchar type column and the column data contains
digits, the MSJDBC driver would conveniently truncates leading zeros and
append ".0000". The new driver fixes this problem. In testing this,
I noticed in the Profiler that all char type columns are typed as
nvarchar when the JDBC driver formulates the sp_exec statement
which is a different behavior from the previous version.