Excellent idea my friend I salute you for your valiant
efforts. I agree with your mention of JDBC being a
much nicer/cleaner interface. And although I would
much rather use JDBC than ODBC, I have some Access
apps that this would do a world of good for. Thanx.

P.S. Are you going to use the currently availabe JDBC
driver, are you going to write your own, or do you
have a newer JDBC driver than the one on the web. The
currently available one does not work with
LI-superserver. Is the super server compatible one
out yet. If it is could you ask the powers that be to
pop it up on their web server.

Edward Flick

--- Jim Starkey <jas@...> wrote:

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

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/