IBPhoenix Development

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
     
This Site Uses:

IBPhoenix Open Source ODBC Driver

Use Right Click and Save As to download.

Latest Installable Builds
Version 1.2

Version 2.0 RC1

Version 1.2.1 (V1.2.00.0070) Latest Libraries

V1.3 (Beta V1.03.00.0096) Latest Libraries

V2.0 Release Candidate 1 Libraries

Examples
  • 22nd Feb 2003 Examples (.zip) (27k)
    Use SQLPutData and SQLGetData, SQLBindCol, SQLBindParam (for blob TEXT and blob BLR), insert procedure, select data from procedure (suspend), select data from execute procedure (1 row). Using multiple threads over a single connection. Two phase commit.
Examples Using ADO (VB)
  • 17th Dec 2003 Examples (.zip) (7k)
    This sample demonstrates the use of ADO from VBScript and HTML, and shows how VBScript and HTML on the client can be used to build a two tier web application for an Intranet.

Interested in doing some development?

Firstly, you'll need to check the source out via CVS. The source tree is located within the Firebird project on SourceForge. This is the most reliable way to get the latest code. You do not have to be a member of the Firebird project to gain access to it.

  • The CVS tree is viewable in a web browser here.

To download the source you need to have a CVS client available. Use the following two commands:

cvs -d:pserver:anonymous@firebird.cvs.sourceforge.net:/cvsroot/firebird login
cvs -z3 -d:pserver:anonymous@firebird.cvs.sourceforge.net:/cvsroot/firebird co OdbcJdbc

There is an MSVC workspace for building the driver for Win32. Make OdbcJdbcSetup the active project and do a build all. There are also make files for other platforms (e.g. Linux and FreeBSD).

Want to talk to other developers working on the driver?

You can subscribe to a list server dedicated to the discussion of driver development issues.

Legal stuff you need to cast a cursory glance at

The driver is available under the Initial Developers Public Licence (IDPL). This is a variation of the InterBase Public Licence (IPL). You can see the licence here.
Main point to take on board is that the essence of the licence is Mozilla (as is the IPL), allowing free compilation and distribution of the code. The licence obviously allows IBPhoenix to retain ownership and copyright of the code. However, unlike the IPL, there is no restrictive schedule appended.

Technical

From a posting by Jim Starkey on IB-Architect, 30th May 2000.

Below is the formal specification of the C++ Jdbc interface that I'm developing as part of the Odbc implementation.

Things that I expect to change before opening the code include:

  1. Dumping openDatabase and createData calls with explicit user and password in favor of the parameter block forms.
  2. Taking the the esoterica from my other project (genHtml, etc).
  3. Adding an abstract class definition for DateTime, TimeStamp, Time and Parameters.
  4. Adding or substracting to cover up sins of omission and commission.
The Blob and Clob classes diverge slightly from the Jdbc specification on the getBytes and getSubString methods. There are two problems. First, in Java, a programmer can get the size of a returned array. Second, in Windows at least, memory allocated in a DLL cannot be safely released from the main program or another DLL, so releasing a byte or character vector is problematic. ResultSet handles the problem by caching the string until the next "next" or "release" call, but I'm uncomfortable about doing this for large blobs. Hence the caller is responsible for memory allocation. I've also added Blob::getSegmentLength and Blob::getSegment calls to support the following sort of loop to avoid the need for explicit memory allocation:
for (int l, offset=0;

l=blob->getSegmentLength(offset); offset +=l) 


printf ("%*s", length, blob->getSegment (offset));
I have temporarily ducked the question of unicode. I think the best solution would to double up all setString and getString calls with getUnicodeString and setUnicodeString. There is a trend towards obscuring the different between Ascii and Unicode with conditional declarations, making most source bi-modal, that I am not comfortable with.

I have also added a StatementMetaData class to support Odbc with functionality not in Jdbc. Necessary, but not a biggie.

I haven't (yet) defined an analog for the Jdbc DriverManager. Connections, for the time being, are created by calling "createConnection" against a known (or loaded) library to get an initial connection object. If (or when) I add a driver manager, it will almost certainly use this mechanism.

Object lifetimes are a little muddled. The Connection object uses the method close() a la Jdbc. Statement and ResultSet have retained close() but also have more civilized addRef() and release(); close() indeed makes the sucker go away, so the two mechanism are sort of complementary. Maybe we should flush close(). The metadata objects (DatabaseMetaData, ResultSetMetaData, and StatementMetaData) live and die with their parent objects. Blobs and Close have only the addRef and release() mechanisms.

The DatabaseMetaDataClass, straight out of Jdbc, is an interesting catalog of almost everything wrong with the SQL standard.

Like Jdbc, there is not explicit support for multiple transactions per process. To get them, multiple attachments are required. There is a temptation to add a clone() method to Connection simplify the coding and allow sharing is the InterBase database attachment.