> re: JDBC w/ LinuxSS
> The currently available one does not work with
> LI-superserver. Is the super server compatible
> one out yet.

Built yes. Released, not yet. When, soon. Would
you like to test it and provide us some feedback?

Markus



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/
>
> ------------------------------------------------------------------------
> Remember four years of good friends, bad clothes, explosive chemistry
> experiments.
> http://click.egroups.com/1/4051/4/_/830676/_/958746098/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com