Microsoft SQL Server 2005 JDBC Driver v1.2 official release


The Microsoft SQL Server JDBC team is proud to announce the general availability of the v1.2 RTW release.  The driver can be found at http://msdn.microsoft.com/data/jdbc.  In this release we significantly reduced the driver’s memory footprint usage especially when handling large clobs and blobs on multiple active connections.  This resulted in performance and scalability improvements, through the use of “responseBuffering=adaptive” connection property.  We also introduced SQL Server SSL encryption support.


Jimmy Wu
Microsoft SQL Server

Comments (23)

  1. L says:

    Can I found release notes somewhere?

    thanks.

  2. Anokun7 says:

    Yes – where can I get the release notes?

    Also is there some performance benchmarking for SSL enabled connections.

    Thanks!!

  3. dpblogs says:

    You can find the release notes within the driver package.

    Thanks,

    Jimmy

  4. mvorobiev says:

    JDBC driver behaves differently for the next query:

    IF (db_id(‘x’) IS NULL)

    BEGIN

     CREATE DATABASE "x";

     SELECT db_id(‘x’) AS id;

    END

    ELSE

    SELECT NULL AS id;

    Ver 1.1 returns a ResultSet or NULL. Ver 1.2 throws an exception if database was created (obviously according to No. 45827 from release notes: The SQLServerStatement.executeQuery method now throws an SQLException if the specified argument, an SQL statement, returns a result other than a single ResultSet). It looks like general approach to executing a number of statements in one query changed: result of the first or last  statement is returned. Which approach is here to stay – 1.1 or 1.2?

    Thanks,

    Michael

  5. Jonas says:

    Looks like you introduced a severe bug in version 1.2: subclasses of Throwable (like SQLServerException) must implement Serializable. However, this is no longer the case for SQLServerException, as it has a StreamError field, which isn’t Serializable anymore in 1.2 (it was in 1.1).

    Is this a known bug?

  6. Jonas says:

    Looks like you introduced a severe bug in version 1.2: subclasses of Throwable (like SQLServerException) must implement Serializable. However, this is no longer the case for SQLServerException, as it has a StreamError field, which isn’t Serializable anymore in 1.2 (it was in 1.1).

    Is this a known bug?

  7. tfan@kronos.com says:

    Hi,

     We are evaluating JDBC v1.2 and found out there is different result with getBytes Method (SQLServerResultSet) call.

    this is output when I tried two drivers:

    using JDBC v1.1

    Timestamp from DB is: 2007-10-26 12:45:45.9

    byte array is:

    0 is -45

    1 is -103

    2 is 0

    3 is 0

    4 is -38

    5 is 82

    6 is -46

    7 is 0

    using JDBC v1.2

    Timestamp from DB is: 2007-10-26 12:44:42.04

    0 is 0

    1 is 0

    2 is -103

    3 is -45

    4 is 0

    5 is -46

    6 is 8

    7 is 4

    you can see first 4 elements values have been changed (with different order).  can someone provide more information about this? Thanks.

    –Tony

  8. dpblogs says:

    Hi Michael,

    Regarding your feedback:

    >Ver 1.1 returns a ResultSet or NULL. Ver 1.2

    >throws an exception if database was created

    >(obviously according to No. 45827 from

    >release notes: The

    >SQLServerStatement.executeQuery method now

    >throws an SQLException if the specified

    >argument, an SQL statement, returns a result

    >other than a single ResultSet). It looks like

    >general approach to executing a number of

    >statements in one query changed: result of

    >the first or last  statement is returned.

    >Which approach is here to stay – 1.1 or 1.2?

    We revisited the JDBC 3.0 spec for "executeQuery" during the v1.2 release and found that our v1.1 driver did not behave 100% as specified.  In revisiting the JDBC 3.0 spec, we saw that it clearly states that "executeQuery" returns a single result set.  The result set may be empty, but it can not be "null".  Consequently, we fixed our driver behavior in v1.2, as you’ve noted.  The v1.2 behavior is here to stay.  We recommend customer needing the ability for SQL Server to return "null" or multiple result sets to use the "execute" API.

    Sincerely,

    Jimmy Wu [MSFT]

  9. dpblogs says:

    Hi Jonas,

    Thank-you for your feedback.  We are currently investigating this.  We will post an update once we have identified the issue.

    Thanks,

    Jimmy Wu [MSFT]

  10. Hi Tony,

    If I understand your scenario correctly, you have a timestamp column on SQL Server (not datetime).  When retrieving the value, you use getBytes() method and the difference in result between v1.1 and v1.2 is what you’ve shown.

    We are currently investigating this, but we would also like to understand if there was a specific reason that you prefered retrieving the value using getBytes() instead of getTimestamp() or getDate().

    Thanks,

    Jimmy Wu [MSFT]

  11. tfan@kronos.com says:

    we use SQL statement select getdate() from DB server to get DB server timestamps, then use getBytes() method for our persistence lay to do real work. I have a sample java program just to get a timestamp from a table  

    and use getBytes() on SQLServerResultSet, you can see the result different:

    v1.2 result:

    2007-10-22 10:04:32.623

    0 is 0

    1 is 0

    2 is -103

    3 is -49

    4 is 0

    5 is -90

    6 is 10

    7 is -5

    v1.1

    2007-10-22 10:04:32.623

    0 is -49

    1 is -103

    2 is 0

    3 is 0

    4 is -5

    5 is 10

    6 is -90

    7 is 0

    first 4 elements order reverse which represents  

    day and last 4 elements also reverse order which represents time.

  12. Yesim says:

    Hi Tony,

    Thank you for your patience. We have investigated the problem you reported and confirmed that it is a not a regression but rather the intended consequence of fixing a defect in v1.1. Basically, the byte order you observe in v1.1 disallows round tripping binary datetime values with the server. You should now be able to do this in v1.2. Hope this helps and thank you for your feedback,

    Yesim [MSFT]

  13. Georg says:

    I see that in the 1.2 driver uniqueness constraint

    violations no longer cause an exception when the insert

    happens within a stored procedure.  The violation is

    silently ignored, the insert is not done.

    Has anyone else seen this?

    Georg.

  14. José Manuel says:

    Hi,

    I’ve found a strange performace with numeric(18,0) column (idPersona) in SQL Server 2000 when do a simple querie: select * from Persona where idPersona=?). IdPersona has a clustered index.

    The query ellapsed this time is it’s used the next java type in preparedstatement (I use setObjet method):

    – java.math.BigDecimal 148 ms

    – java.util.Long 243

    – java.util.Integer 4 ms.

    ¿Why is very faster use Integer Java Object instead BigDecimal, if JDBC SQL mapping is BigDecimal -> NUMERIC -> numeric?

  15. Evan T. Basalik (MSFT) says:

    If I am following your question correctly, it looks like you are sending the WHERE clause across with a different Java type in each case.  When the JDBC driver sends that type across, the type is converted by the driver to a specific SQL type.  For example, the correlations for the 1.5 JVM can be found here – http://java.sun.com/j2se/1.5.0/docs/guide/jdbc/getstart/mapping.html#996857.

    Since you are using three different Java types, you are likely going to get three different SQL types sent across the wire.  When the SQL Server query optimizer then tries to figure out the best execution plan, part of that execution plan may be converting the type sent across to the field type.  Depending on the conversion, this can result in a more or less efficient query.  Less efficient queries take longer to run.

    I would compare the type you are sending across and make sure you are using the correct Java type to match your SQL type.  If you are and the query is still slower than you would like, you can examine the execution plan to see if adding an index or changing to another field type would result in a better execution plan.

  16. vinayagamrk says:

    Whenever there is a upgrade or a new release or new version of any software it should have the backward compatibility. Here I am trying to connect MSSQL Server 2000 using MSSQL Server 2005 JDBC driver. Most of the functionalities are working (Hope so). But still there are some issues while trying access a stored procedure which intern talks to Oracle RDBMS thru Microsoft data transformation services, It throws some SQL exception say “This statement did not return any result sets. But the same code is working fine with MSSQL Server 2000 JDBC driver. This supposed to be fixed.

    -Vinay

  17. Greale says:

    I have an application run with SQL2000 originally, last month the database has been migrated to SQL2005, I’ve updated the jdbc driver to version 1.2 accordingly, but found the performance of the application is greatly downgrade, it take around 4 times as long as before for the same task.

    Anyone can guide me to fix such problem?

    Thanks in advance

    Greale

  18. dpblogs says:

    Hi Greale,

    Thank-you for your feedback.  It will greatly help us if you can elaborate on how you are measuring the 4x slow down between SQL2000 and SQL2005.  Are you using the same driver against the 2 SQL Server versions?  

    Without knowing specifics, here are some general performance guidelines for the v1.2 driver:

    – set ResponseBuffering=true on the connection.

    – avoid the need to have 2 concurrently active statements or resultsets.  Close out the one you no longer need.  This will prevent the driver having to buffer the data in memory.

    – revisit the SQL Profiler tool to make sure the same stored procedure performs the same between SQL2000 and SQL2005.

    If the above recommendations does not improve performance, I recommend contacting Microsoft Support.  They will be able to better assist you.

    Jimmy

  19. Geale says:

    Hi Jimmy,

    Thanks for your reply.

    I uses the JDBC for SQL2000 before the db migration.

  20. Praveen says:

    Hi

    we are using the Microsoft SQL Server 2005 JDBC in sap Application , and the legacy system has MS SQL 2000 JDBC driver

    Will these be compatible if we have diffeent versions of the Servers in the both ends.

    Please let me know if any one has solution for these.

    Thansk

    Praveen

    Will the Ms SQL 2005 is installed

  21. Deepak says:

    The getBytes() method is buggy. It throws an exception

    "com.microsoft.sqlserver.jdbc.SQLServerException: The conversion from int to BINARY is unsupported."

    when I am trying to get a short variable and the getColumnTypeName() says its a "smallint" !! Please advise

  22. Pragatheeswaran says:

    I cannot find "Microsoft SQL Server 2005 JDBC Driver v1.2" in this link.