I am currently writing a new Odbc driver for InterBase (living
with Ann sometimes has its downsides). Though in general it
is about as exciting as growing rocks in New England, there
are the odd points here and there to do something interesting.
I would appreciate any feedback, suggestions, warnings, and
(even) encouragement possible.

The approach I'm taking is a little unusual. In a nutshell,
I'm building a JDBC compliant, C++ encapsulation of the InterBase
API and a generic Odbc driver layered on the C++ JDBC encapsulation.

Let me make it clear what I mean by a JDBC compliant C++ encapsulation.
First, it has nothing to do with Java other than the documentation.
The encapsulation is a set of abstract C++ classes (Connection,
Statement, PreparedStatement, ResultSet, DatabaseMetaData, and
ResultSetMetaData) that mimic the corresponding JDBC interfaces.
Other than adding a Blob type (JDBC uses InputStreams and OutputStream,
which I though we a bit much) and adding addRef/release to each
class to compensate for a lack of automatic garbage collection, the
encapsulation is semantically identifical to the JDBC counterparts.
So, for complete docuementation, see the JavaSoft JDBC docs.

For those of you unfamiliar with Java and JDBC, the general scheme
of things is like this: Starting with a Connection object, you
call a method prepareStatement with a sql string to get a
PreparedStatement object. If there are parameters required, they
are set in the PreparedStatement object (setInt, setString...).
The method PreparedStatement.execute returns a ResultSet object.
The boolean valued ResultSet.next method advances the cursor.
Values are fetched directly from the ResultSet object (getInt,
getString...). All errors are throw as exceptions (SQLException)
rather than returned as codes.

The reason that I'm doing this is a major dearth of good database
APIs, particularly clean ones for OO languages. The InterBase
DSQL interface was originally lifted lock, stock, and barrel from
DB2 (in the interest of standards compliance where there was not
standard), and has grown rather long in tooth. ODBC, in my
humble opinion, is useful but technically deplorable. And the
new SQL API is, well, uh, shall we say regretable.

JDBC is simple, squeeky clean, and well defined. It requires
no ancillary data structures to use. It follows strong typing
rules. Since an object instance simply inherits from the
formal interface, extensions are easy and safe.

I would like to see the C++ JDBC encapsulation become the primary
supported InterBase API over time. I would also like to see the
C++ JDBC binding become the industry standard API.

So, to prime the pump, I'm basing the new ODBC driver on this
interface. Some answers to obvious questions:

Q: What is the overhead involved in a two level driver?
A: Virtually none. JDBC was designed for an ODBC/JDBC
bridge, so the semantics meshly nicely, requiring
essentially no translation.

Q: What is the ODBC driver written in?
A: C++.

Q: Will JDBC encapsulation be usable without the ODBC
driver?
A: Of course.

Q: Will the code be open sourced?
A: Yes. Probably before the InterBase source code itself.

Q: Will all InterBase functionality be available?
A: Not initially. Multiple transactions per process,
events, and arrays have no support in either JDBC
or ODBC. ODBC extensions are architecturally
impossible. Any instance extensions to JDBC will
be discussed before they are made.

Q: What ODBC level?
A: Basic with some Intermediate.

Q: What about scrollable cursors.
A: Eventually, don't know when. When I get there, I'll
let you know.

Q: What platforms?
A: At least Win32 and Linux.

Q: Do I need Java on my system?
A: No. Only the Java documentation.


Jim Starkey