Microsoft JDBC Driver Team Blog : JDBC

v2.0 January 2009 Community Technology Preview Released

dpblogs — Tue, 27 Jan 2009 04:24:00 GMT

The SQL Server JDBC team is happy to announce the release of the January 2009 community technology preview. This beta release is feature complete, which includes, but not limited to, JDBC 4.0 SQLXML data type; National Character set; driver autoloading; new metadata methods; and enhanced tracing. You can download the beta release at http://msdn.microsoft.com/data/jdbc.

Jimmy Wu
SQL Server JDBC Team

SQL Server 2005 JDBC Driver and Database Mirroring

dpblogs — Tue, 06 Jan 2009 01:30:00 GMT

We've heard from some customers that they are having difficulty getting Database Mirroring to work with our JDBC driver. Recently, Adam from our counterpart customer service team posted a great blog on this topic. Please refer to his blog regarding a couple of gotchas with the v1.2 driver.

http://blogs.msdn.com/psssql/archive/2008/12/31/sql-2005-jdbc-driver-and-database-mirroring.aspx

Jimmy Wu
SQL Server JDBC Team

Working with SQL Server 2008 Filestream using v1.2 JDBC driver

dpblogs — Sat, 04 Oct 2008 03:44:00 GMT

In the previous post "Working with SQL Server 2008 Date/Time Data Types using v1.2 JDBC driver",I talked about how the current JDBC driver can interop with the new Date/Time/DateTime2/DatetimeOffset data types. This time around, I will describe how to interop with SQL Server 2008 Filestream.

Please refer to "SQL Server 2008 Books Online" for detailed information about Filestream.

To demostrate how the v1.2 driver can retrieve a resultset containing a filestream column, I used the following T-SQL query to create the test database and table:

CREATE DATABASE Archive
ON
PRIMARY ( NAME = Arch1,
    FILENAME = 'c:\data\archdat1.mdf'),
FILEGROUP FileStreamGroup1 CONTAINS FILESTREAM( NAME = Arch3,
    FILENAME = 'c:\data\filestream1')
LOG ON ( NAME = Archlog1,
    FILENAME = 'c:\data\archlog1.ldf')
GO

CREATE TABLE foo
(
   id int NOT NULL PRIMARY KEY,
   Photo varbinary(max) FILESTREAM NULL,
   MyRowGuidColumn uniqueidentifier NOT NULL ROWGUIDCOL
   UNIQUE DEFAULT NEWID()
)
GO

Let's assume that the table has already been populated with some data. Here is the code snippet that I used to retrieve the column values:

strCmd = "select * from foo";
rs = stmt.executeQuery(strCmd);
if (rs.next())
{
    ResultSetMetaData rsmd = rs.getMetaData();
    if (null != rsmd)
    {
        String x = rsmd.getColumnTypeName(2);
        String name = rsmd.getColumnName(2);
        System.out.println("Column " + name + " is data type: " + x);
        int i = rsmd.getColumnType(2);
        switch (i)
        {
        case (java.sql.Types.LONGVARBINARY):
            System.out.println("Column is of JDBC type LONGVARBINARY.");
            InputStream bStream = rs.getBinaryStream(2);
            byte[] y = new byte[1024];
            if (null != bStream)
            {
                // write the retrieved filestream data as a file.
                System.out.println("Write the filestream data out as a file.");
                FileOutputStream fs = new FileOutputStream("c:\\myFile");
                int read = bStream.read(y);
                while (read != -1)
                {
                     fs.write(y);
                    fs.flush();
                     read = bStream.read(y);
                }
                fs.close();
            }
            break;
        default:
            throw new Exception("Unexpected data type found: " + String.valueOf(i) + ". Expected LONGVARBINARY.");
        }
    }

    // now, update the data with a new file content.
    System.out.print("Now, let's update the filestream data.");
    FileInputStream iStream = new FileInputStream("c:\\testFile.xml");
    rs.updateBinaryStream(2, iStream, -1);
    rs.updateRow();
    iStream.close();
}
rs.close();

When executed as a console application, you'll get the following output:

Column Photo is data type: varbinary
Column is of JDBC type LONGVARBINARY.
Write the filestream data out as a file.
Now, let's update the filestream data.

As you've probably already noticed, SQL Server 2008 Filestream is simply a LONGVARBINARY to the v1.2 JDBC driver. This means you can operate on a Filestream like any other LONGVARBINARY, though I recommend that you stick with binaryStream to minize the amount of buffering the driver has to do.

Jimmy Wu
SQL Server JDBC Team

The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption.

dpblogs — Wed, 10 Sep 2008 03:26:00 GMT

What is SSL and why is my JDBC driver using it?

The v1.2 JDBC driver uses SSL (Secure Sockets Layer) to encrypt connections to SQL Server for improved security. Where it can, the v1.2 driver ALWAYS uses SSL to encrypt the login to SQL Server. For integrated auth connections, SSL provides an added layer of security. For SQL auth, where the user name and password would otherwise be sent in the clear, SSL provides an essential layer of security.

I trust that my network is secure without SSL... How do I turn off SSL encryption?

You can control whether a connection encrypts all data to and from the server after login using the ‘encrypt’ connection property. However, where it can, the v1.2 driver ALWAYS uses SSL to encrypt the login to SQL Server. You cannot disable SSL encryption of the SQL Server login.

Ok, but I upgraded to v1.2 and now I can’t connect! Why am I getting the error “The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: …”?

Odds are good that your Java SSL setup is messed up somehow.

SSL in Java is provided through the Java Secure Socket Extension (JSSE). Its reference guide (for J2SE 5) is here: http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html . A key aspect of JSSE is its pluggable provider model. Typically, JRE vendors supply JSSE provider implementations. There are at least two main JSSE providers available out there and they do not necessary work well together.

For SSL to work at all, it is absolutely necessary to have the JSSE providers configured correctly for the JRE you are using. There are two steps to this:

1) Look at the java.security file in your JRE installation (typically found in the jre\lib\security directory). The installed security providers are listed in that file as security.provider.x=… where ‘x’ is the priority used. For Sun JRE installations, the first priority provider should be Sun’s. E.g.: you should have the line “security.provider.1=sun.security.provider.Sun” in that file. For other JRE's, please refer to the JRE's documentation regarding their default provider name. We recommend when using the IBM JRE to specify the "com.ibm.jsse.IBMJSSEProvider" as the first security provider to use.

2) Next, make sure that the classpath points to the correct JAR files (in the jre\lib directory) for use with those providers. For Sun, the classpath should include jsse.jar. For IBM, should include ibmjsse.jar.

If either the classpath or the java.security file is not correct, SSL will not work. Not just with SQL Server, but with anything else either.

SSL works for other apps, just not with JDBC. And I’ve verified that the classpath is correct… Check certificates

If you are going to configure SQL Server to use a server certificate, then that certificate needs (or the certificate of one of its trusted issuing authorities) needs to be present in Java’s certificate store. If the certificate isn’t there, chances are that your JSSE provider will give you a nice descriptive, if sometimes cryptic, error. Configuring the client for use with SSL is covered in our docs here http://msdn2.microsoft.com/en-us/library/bb879943.aspx . Some certificates are quite large and trip up older JSSE providers. Of course there may be other VMs out there with similar problems, but we are not able to verify all of them. A smaller certificate may help in this case.

Not a configuration problem or a certificate problem. Now what.

When contacting Microsoft to help us be effective, we need to be armed with the following info:

1) The complete text of the error message. I.e. including the part after “Error: …” above.

2) A stack trace (if available).

3) A complete log (if available) containing FINEST TDS-level traces leading up to the error. In particular, the following loggers should be enabled in the logging properties:

com.microsoft.sqlserver.jdbc.TDSChannel.level = FINEST

com.microsoft.sqlserver.jdbc.TDSReader.level = FINEST

com.microsoft.sqlserver.jdbc.TDSWriter.level = FINEST

com.microsoft.sqlserver.jdbc.TDS.DATA.level = FINEST

Generating the log file with the XMLFormatter is preferred over SimpleFormatter, as it gives us more info.

4) The java.security file that was used.

5) Vendor and version of the JRE used.

6) SQL Server version

7) The connection string/connection properties used.

David Olix & Jimmy Wu

SQL Server JDBC Team

SQL Server JDBC driver v2.0 beta is now available

dpblogs — Wed, 23 Jul 2008 21:48:00 GMT

We are proud to announce the availability of our beta v2.0 driver with support for JDBC 4.0 National Character Set JDBC data types and API methods among others. We have also enhanced our built-in tracing leveraging the Java logger utility by adding method entry and exit traces and better differentiation between the logger levels.

The beta driver is available at http://msdn.microsoft.com/data/jdbc

We welcome all feedback as we continue to improve this driver for the community.

Jimmy Wu
SQL Server JDBC Team