JDBC 2.0 implementation

Last updated. December 17 2002


1.- Introduction

This document is focused on feature coverage of the JDBC 2.0 specification and performance.

For more information about the driver and how to use it, please read the release notes and FAQ.

2.- Connection URL

The driver URL syntax has two forms:

Standard format= jdbc:firebirdsql:[//host[:port]/]<database>
FB old format= jdbc:firebirdsql:[host[/port]:]<database>

3.- JDBC Features

The driver complies with the JDBC 2.0 core with some features and methods not implemented. Some of the unimplemented features are required by the specification and some are optional.

The following optional features and the methods that support it are not implemented:

Excluding the unsupported features, the following methods are not yet implemented:

The following methods are implemented, but do not work as expected:

4.- Compliance Tests

JDBC 2.0 compliance was checked with Sun JDBC CTS 1.3.1 test suite. Driver passed all relevant tests (totally 1216 tests), excluded tests can be checked in the CVS in client-java/src/jdbccts/excludes.properties. This file also contains explanations why the test was exluded. There are two main groups of test cases that were excluded: BIT data type tests and tests that fail due to rounding problems in floating-point numbers within the Firebird itself. BIT data type is not yet supported by Firebird and rounding problems will be checked with server team. Some tests were excluded due to errors within the tests themselves, this will be checked with Sun Microsystems later.

5.- Performance recomendations

Updates, deletes etc

Don't use executeUpdate when you don't need the affected record count. Because the database doesn't send this information to the result, the driver must request it after the execution finishes, and it needs some time to do it . Use execute() instead of executeUpdate() when count is not needed.

Character encoding

In FB the client notifies the server which character set it will use in the communication. The server then converts all the incoming character information from this character set to the one of the field or database. In the output the server also does the conversion from the database/field character set to the one needed by the client.

This driver sets as the default the NONE character set, the same that Interclient uses. It seems there are some performance problems in the engine and when the NONE character set is received it takes some time to convert it to the character set of the field/database. When using NONE, the theory is that the server only verifies that the characters received are valid characters.

When using a character set other than NONE in the database, set the lc_ctype parameter equal to the database default charset. If you can, select the database default character set to be equivalent to the default character set of your JVM.

Also you can set the default character set of the database to NONE, but this is not recommended since other tools that can be used with the database can't know which character set is in use.

Apparently, there can be some problems if the database uses character set NONE and the lc_ctype parameter is set to WIN1252.

  A) RC2 B) RC2 C) RC2 time B/A(%) time C/A(%)
Client lc_ctype NONE WIN1252 NONE    
DB default charset WIN1252 WIN1252 NONE    
IMPLICIT TRANSACTION CONTROL
Insert short record of Char 14719 13547 12844 92 87
Insert long record of Char 10218 8656 8453 85 83
Insert short record of Varchar 14016 13484 12828 96 92
Insert long record of Varchar 9172 8406 8031 92 88
EXPLICIT TRANSACTION CONTROL
Insert short record of Char 4594 3579 3469 78 76
Insert long record of Char 4500 3110 3063 69 68
Insert short record of Varchar 4109 3672 3578 89 87
Insert long record of Varchar 3609 2985 2922 83 81