RE: [gtk-list] Re: GNOME Database kit ODBC interface



STOP IT NOW ... 

ODBC is bad, bad, bad ... it is poison, dont use it.

All you need for a GNOME generic database interface is the following
collection of functions -

- result_set* execSQL (char *str);       where str is an SQL statement
to execute. Returns a result set *
- char* getValue (result_set *, int row, int column);

The result set structure should contain information such as :
for a 'select' type of result -
- A status saying whether the call failed or succeeded
- Number of rows in the result set
- Meta information on the types of data in the columns of the result set
for an update type of result -
- A status saying whether the call failed or succeeded
- Number of rows updated

This is based on the PostgreSQL C lib functions, but writing wrappers to
things like Oracle using OCI routines, or Informix, etc is very trivial
and very high-performance. Writing an ODBC driver from scratch is almost
impossible in comparison, and at the end of the day you have a very high
level interface that slows down your database, and removes all control
from the programmer. If you want to get a feel for ODBC before writing
any code, try putting on some Ski Gloves and tieing your shoelaces a few
times. 

ODBC is another microsoft 'innovation' - lets say you want to write an
ODBC driver for mySQL .. first port of call would be to go to the M$
website and search the 'Knowledge Base' for the specs for the ODBC
interface. Good luck ...   After about a week of painful searching you
will discover that ODBC is not a 'spec' like you would expect to find,
but rather a 'collection of concepts and technologies' which are not
documented in any detail anywhere that I could find.

The best thing that I can suggest that you do is to write some useful
applet that talks to a known database. Use every trick that the database
library allows you to use. Now, port the applet to a second database.
Repeat the port for a third database. Now, look at which bits are
common, which bits need to be wrapperized, and do it in such a way that
you can still optimize your applet to make use of special tricks offered
by certain databases.

just my 2c



> -----Original Message-----
> From:	Walt Pohl [SMTP:pohl@math.washington.edu]
> Sent:	Friday, 7 August 1998 10:14
> To:	gtk-list@redhat.com
> Subject:	[gtk-list] Re: GNOME Database kit
> 
> 
> I think ODBC drivers are supposed to be hard to write.  There's also a
> data-base interface in the CORBA spec, so it probably makes sense to
> have
> the higher layer of abstraction, so that you can support both.
> 
> On Thu, 6 Aug 1998, Johannes Keukelaar wrote:
> 
> > First of all, a database front-end is definitely an application that
> GNOME 
> > needs. However...
> > 
> > //Database cursor abstraction layer which currently works only for
> ODBC.
> > //
> > //Next steps:
> > //
> > //Shared lib and dynamic load support in the DB login widget and the
> DB
> > //cursor  layer to allow different DB backends (ODBC, postgres,
> plain
> > //text files).
> > 
> > Isn't ODBC an abstracted, general interface already? Why add your
> own layer of abstraction over that? If you support ODBC, and someone
> wants to use it with some weird database system, all you have to do is
> write an ODBC driver, which is going to be more generally useful. (Of
> course, I don't know how simple it is to write an ODBC driver, but
> that's another story.) Besides, aren't there quite many ODBC drivers
> out there already? Why add unnecessary complexity?
> > 
> > Regards,
> > 
> > Johannes.
> > --
> > "The only luxury is freedom, freedom of the mind. They can chop off
> my head
> > and take everything else as long as they leave me that." -Dieter
> Meier of Yello
> > 
> > How do I connect to that real-life thing I keep hearing about?
> > 
> > 
> > -- 
> > To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com <
> /dev/null
> > 
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com <
> /dev/null



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]