Microsoft SQL Server 2005 JDBC Driver v1.2 official release

Microsoft SQL Server 2005 JDBC Driver v1.2 official release

  • Comments 23

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

Leave a Comment
  • Please add 6 and 8 and type the answer here:
  • Post
  • PingBack from http://www.artofbam.com/wordpress/?p=8019

  • Can I found release notes somewhere?

    thanks.

  • Yes - where can I get the release notes?

    Also is there some performance benchmarking for SSL enabled connections.

    Thanks!!

  • You can find the release notes within the driver package.

    Thanks,

    Jimmy

  • 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

  • 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?

  • 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?

  • 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

  • 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]

  • 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]

  • 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]

  • 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.

  • 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]

  • 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.

  • 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?

Page 1 of 2 (23 items) 12