Release Information Microsoft SQL Server 2005 JDBC Driver Version 1.0 January 2006 INTRODUCTION ------------ This file contains late-breaking or other important information that supplements the Microsoft SQL Server 2005 JDBC Driver documentation. You should read this file completely before installing the JDBC driver. Your feedback is very important to us and we will therefore strive to respond to your feedback in a timely manner. For information about providing feedback using the JDBC driver newsgroup on online forums, see the Microsoft SQL Server 2005 JDBC Driver page at http://msdn.microsoft.com/data/jdbc. INSTALLATION ------------ Instructions for installing the JDBC driver are located in install.txt. Please refer to that file for information about installing the JDBC driver on Windows and Unix platforms. RELEASE CONTENTS ---------------- The Microsoft SQL Server 2005 JDBC Driver executable zip or tar file will unpack the following files in the specified locations, relative to the selected installation directory: \sqljdbc_1.0\\install.txt \sqljdbc_1.0\\release.txt \sqljdbc_1.0\\license.txt \sqljdbc_1.0\\sqljdbc.jar \sqljdbc_1.0\\help\default.htm \sqljdbc_1.0\\help\index.htm \sqljdbc_1.0\\help\toc.htm \sqljdbc_1.0\\help\html\ \sqljdbc_1.0\\help\local\ \sqljdbc_1.0\\xa\xa_install.sql \sqljdbc_1.0\\xa\xa_install.txt \sqljdbc_1.0\\xa\x86\sqljdbc_xa.dll \sqljdbc_1.0\\xa\x64\sqljdbc_xa.dll KNOWN ISSUES ------------ The following are known issues with Microsoft SQL Server 2005 JDBC Driver: 1) DRIVER LOAD CONFLICT WITH SQL SERVER 2000 JDBC DRIVER If you load both the Microsoft SQL Server 2000 JDBC Driver and the Microsoft SQL Server 2005 JDBC Driver in the same process, in some cases the 2000 version of the JDBC driver will improperly accept a DriverManager.getConnection method call that is targeted for the 2005 version of the JDBC driver. The problem is caused by the 2000 version of the JDBC driver incorrectly accepting the "jdbc:sqlserver://" URL prefix if it is loaded first. Microsoft is aware of this issue and is planning to fix it in the 2000 version of the JDBC Driver. To work around this issue, load the 2005 version of the JDBC driver class first, as follows: Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver"); // 2005 version Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver"); // 2000 version This will ensure that the "jdbc:sqlserver://" URL prefix is handled by the 2005 version of the JDBC driver and the "jdbc:microsoft:sqlserver://" URL prefix is handled by the 2000 version of the JDBC driver. 2) LIMITATIONS GETTING PARAMETER METADATA FOR PREPARED STATEMENTS There are some limitations when using the SQLServerParameterMetaData class with prepared statements. SQL INSERT statements require the optional INTO clause and SQL DELETE statements require the optional FROM clause to get the parameter metadata correctly. 3) SQL SERVER 2000 DATA CONVERSION LIMITATIONS When using SQL Server 2000 with the JDBC driver, the following data conversion limitations apply: - String data cannot be converted to an underlying money or smallmoney column. - String data longer than 4000 characters cannot be converted to char or varchar underlying columns. - String data more than 4000 characters cannot be converted to nchar or nvarchar underlying columns if the sendStringParametersAsUnicode connection string property is set to false, or the setAsciiStream method is called. - String data cannot be converted to text columns if the sendStringParametersAsUnicode connection string property is set to true. If you need to support string to text columns conversions, set the sendStringParametersAsUnicode property to false. 4) LIMITATIONS WITH NAMED PARAMETERS Named parameters are not supported with stored procedures that contain a left bracket "[" in their name. For example, a name like "stor[edProc". Note that this does not affect the usual escaping of the stored procedure names using "[]". 5) TRIGGERS AND UPDATE COUNTS A prepared or callable statement that fires one or more triggers when it is executed may return an incorrect update count. This occurs when the lastUpdateCount connection property is set to true (the default). If any of the fired triggers produces an update count of its own and does not use a SET statement, then the update count from the first such trigger is returned instead of the update count from the statement's execution. The same behavior exists with stored procedure calls executed as normal statements. To work around this issue you may configure SQL Server not to return update counts from trigger execution by issuing the following Transact-SQL statements: USE master; GO EXEC sp_configure 'disallow results from triggers', '1'; RECONFIGURE WITH OVERRIDE; Note that if you do not need prepared or callable statement execution, you may avoid this issue by using a regular Statement object rather than a PreparedStatement or CallableStatement object.