You bet I would, anything even partially working would
be beneficial to both our parties. hehe.

Edward Flick

--- Markus Kemper <mkemper@...> wrote:

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

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