Announcing Microsoft SQL Server JDBC Driver 2.0

Announcing Microsoft SQL Server JDBC Driver 2.0

Rate This
  • Comments 39

We are excited to announce the newest release of the Microsoft SQL Server JDBC Driver 2.0!

 

This version of the JDBC driver supports features introduced in the JDBC 4.0 API, including:

·        national character set data types: NCHAR, NVARCHAR, LONGNVARCHAR, NCLOB

·        SQLXML data type

·        Wrapper interface to access SQL Server JDBC Driver specific methods

·        client info properties

·        new database metadata methods

·        LOB creator methods

 

The 2.0 driver also adds:

·        default adaptive response buffering behavior

·        support for SQL Server 2008 collations

·        enhanced tracing, including public method entry and exit traces

·        performance improvements and bug fixes

 

Please feel free to download a copy and see for yourself!

Leave a Comment
  • Please add 5 and 3 and type the answer here:
  • Post
  • I'm so disappointed by the result of performance optimization for ParameterUtils.scanSQLForChar() and it's caller. The optimization should be more deeper.

    I think if your team open source, I can give a patch for the performance.

    I posted on forum:http://social.msdn.microsoft.com/forums/en-US/sqldataaccess/thread/ace7badf-90d7-4fd7-aebb-6f09af62077f/

    contact me :lunxian@hotmail.com, if neccessarily.

  • Dear Sir

    Can I use JDBC 2.0 to connect to MS-SQL SQL-Server 2009? I believe it will be released soon.

    Thanks in advance and Sorry for any inconvenience.

  • The short answer is "yes". However, I'm not sure if we've announced an official product name for the next release of SQL Server. The next release is code named "Kilimanjaro".

    JDBC 2.0 will connect to it but only as a down-level client. When down-level conversions are allowed, applications can execute queries and perform updates on the new SQL Server data types - such as time, date, datetime2, datetimeoffset, FILESTREAM, and other items introduced in Killimanjaro. For more information about how to use these new data types with the JDBC driver, see Working with SQL Server 2008 Date/Time Data Types using JDBC Driver (http://go.microsoft.com/fwlink/?LinkId=145198) and Working with SQL Server 2008 FileStream using JDBC Driver (http://go.microsoft.com/fwlink/?LinkId=145199).

    For more information about the down-level compatibility of these new data types, see Using Date and Time Data (http://go.microsoft.com/fwlink/?LinkId=145211) and FILESTREAM Support (http://go.microsoft.com/fwlink/?LinkId=145212) topics in SQL Server Books Online.

  • can you give me some advice?

    I create a table with varchar column,if input all English words, it can be displayed well, but if contain Simplified Chinese characters there is nothing to display.

    <%

    ...

    out.print(rs.getString("name"));

    ...

    %>

    no exception or something prompte.

  • my environment is sql server 2008 enu, jboss 5.0, used sqljdbc4.jar.

  • i changed varchar to nvarchar that's ok!

    sorry for disturbed.

  • Here's a problem i noticed with this new driver. When you get a binary stream

    InputStream s = resultSet.getBinaryStream("filedata");

    and then try to to return this stream after closing the connection you get an error when attempting to read from this stream. This wasn't the behavior in the previous driver. In the previous driver you could have methods like this

    //NOTE this is pseudo code

    public InputStream getBlobStream() {

       connection  = pool.getConnection()

       statement = onnection.createStatement();        

       resultset = stmt.executeQuery("select blob from blob");

      InputStream s = resultSet.getBinaryStream("filedata");

      connection.close();

      return s;

    }

    In the new driver, closing the connection or releasing it back to the pool closes the steam on the result set. This is really poor behavior IMO since you can no longer pass a stream around without worrying about the underlying DB connection.

  • Hi Max,

    The JDBC specification for Connection.close() says that the method "releases this Connection object's database and JDBC resources immediately".  That means releasing resources associated with all of the Statements, ResultSets, InputStreams, etc. that were created in the context of that Connection.

    Your repro relies on the driver not behaving per the JDBC specification in that respect in this particular situation.  My first recommendation would be to fix the repro not to depend on the incorrect driver behavior as we may correct the behavior at any point to align with the JDBC spec.

    That said, the likely cause of the difference in behavior is the change to default to adaptive response buffering in the 2.0 driver.  So you may be able to restore the previous behavior by setting the connection property responseBuffering=full.  But in doing so, the repro still relies on a driver bug.

    Regards,

    --David Olix [SQL Server]

  • what about Table-valued parameters support in JDBC driver?

  • Hello Palesz,

    This release of the JDBC driver was targeted towards the JDBC 4.0 specification. However, we are in the planning stage of our next driver and would love to hear feedback from you. Do you mind heading here and letting us know what features you'd like to see in the next version of our driver? http://blogs.msdn.com/jdbcteam/archive/2008/10/14/sql-server-2008-feature-support-survey.aspx

    If possible, please include your intended usage scenario. We appreciate it.

    Thanks,

    --Tres London [SQL Server]

  • (I apologize if this shows up twice...my first time responding on MSDN blogs, and after hitting the Submit button once, I didn't see my response appear)

    I'm using the 2.0 driver and am having some issues with XA Transactions not properly aborting.  I wonder if you could possibly shed any light on the matter, or provide any advice for tracking the issue down.  Here's a link to a posting to the Glassfish forum describing some of the details:

      http://forums.java.net/jive/thread.jspa?threadID=61749&tstart=0

    In short, I'm using glassfish to get an XADataSource to connect to a SQL Server 2005 database, and most things seem to work properly.  I can begin transactions, commit them, and even explicitly do a rollback().

    The problem I am having occurs when the clien app (NOT the app server) closes unexpectedly.  The XA transaction times out, SQL Server still seems to continue to hang on to resources (locks) and there seems to be a "hanging" UOW with connection id "-2" hanging around.  If I use a different DB server (Derby) the XA Abort seems to work properly.

    Any thoughts?  Any way to tell if SQL Server actually receives word that it ought to abort the transaction?

    At least one other person seems to have had a similar problem, and provided a concise description here:

      http://www.sqlmonster.com/Uwe/Forum.aspx/sql-server-jdbc/1043/xa-connection-issues

    Any help is appreciated.  Thanks in advance.

  • i have changed my my driver to JDBC Driver 2.0 and i am facing a problem. Some of the stored procedure which were working in my web application are now not working now.

    I am using sqljdbc.jar. I am getting "com.microsoft.sqlserver.jdbc.SQLServerException: The statement did not return a result set" I can see that from query analyzer it is returning values. I have tried different combination of executeQuery and all are returing the same. Am i missing something ?

  • I have found solution in following link

    http://blogs.msdn.com/jdbcteam/archive/2008/08/01/use-execute-and-getmoreresults-methods-for-those-pesky-complex-sql-queries.aspx

    Apologize for not checking the link before. Posting here in case some one else need a direction :)

  • Since jdbc 1.2 driver it appears some uniqueness constraint violations no longer cause an exception when the insert is inside a stored proc.

    There is one application that I have (running Java 1.6), that uses JDBC 1.1 and raises a SQLException but if I take the same application and swap out the JDBC driver 1.1 with either a 1.2 or 2.0, it no longer generates a Java SQLException.

    I have written a small prototype application to try and determine what might be going on but now all three (driver versions) raise the exception as exepected!

    I notice in the 1.2 driver release blog of this msdn blogs, Georg also has the same issue but nobody replied.

    Any ideas on what might be the cause of this?

    Thanks

    ECS

  • Hi ECS,

    You mention that the INSERT is inside a stored procedure.  If that isn't the only statement in the stored procedure, what other statements are executed?  Are any statements executed before the one which is expected to generate the constraint violation?  How is the stored procedure called: execute, executeUpdate, or executeQuery?  Do the comments at http://blogs.msdn.com/jdbcteam/archive/2008/08/01/use-execute-and-getmoreresults-methods-for-those-pesky-complex-sql-queries.aspx apply to your scenario?

    Regards,

    --David Olix [SQL Server]

Page 1 of 3 (39 items) 123