Re: ODBC

In article <3lgo8a$d07@newshost.centrum.is>, Baldvin Hansson <baldvnh@centrum.is> writes: |> jtn@jd.se (Thomas Nimstad) wrote: |> > |> > Baldvin Hansson <baldvnh@centrum.is> writes: |> > >clawton@mailhub.tfs.com (Chris Lawton) wrote: |> > >> We're about to start a new project, and we're interested in ODBC. |> > > We planned to use ODBC instead of Btrieve. BAAAAD Move! 180 Degr. turn |> > > right into the arms of Btrieve after only two months in ODBC HELL! |> > |> > Well, IMHO, that had nothing to do with ODBC ! It was probably the |> > difficulties you came across when using a SQL based language instead |> > of a record based (out-of-date) format. |> > |> > // JTN <jtn@jd.se> |> > |> > --- |> > * Thomas Nimstad * #pragma message("Standard disclaimer in use") |> > * Juristdata AB, SWEDEN * Professional development for Win32 |> > * Phone +46-500 412150 * Fax +46-500 412848 |> |> SQL Is easy, the speed factor was the killer. Every driver we tried |> turned out to be from two, to hundreds of times slower than pure |> Btrieve. |> |> Baldvin Hansson You completely missed his point. He didn't mean that you had trouble mastering SQL; he means that the SQL-to-heirarchical mapping is tough to get and will trip any ODBC driver. I've written an ODBC driver for DB2; the performance is terrific. The main issues are completely different than you might think - the fetch loop is not where we live and die; rather, it is in optimizing the ODBC data stream, including special catalogs, block fetches, and general mapping of ODBC paradigms to DB2-land. I have also considered writing a driver for IMS. This is a MUCH harder task since there is no clear mapping between the relational access language (SQL) and heirarchical object modeling. Rather, a better approach is to create a completely different access method altogether. ODBC tried to accomplish this with NAV (the navigational data model) but failed (NAV got recalled). ODBC is just a spec. There is virtually no overhead associated with using ODBC over any proprietary API's (DB-Lib / OCI / etc). Performance is only affected by the quality of the driver **AND** the quality of the application. In other words, a lowest commond denominator approach for both components will doom the architecture; a well-written driver (like NEON Systems') and a thoughtfully written app (Powerbuilder, MultiLink/VB, Jet 2.0 are STARTING to get there) will have good performance. ODBC got bad rap in its infancy because Microsoft hired Pageahead Software to write the drivers for them. Unfortunately Pageahead did not do such a good job, and more importantly, the data sources did not lend themselves to a relational mapping. BTrieve, FoxPro, Access (database), dBase, etc are not good candidates for ODBC. Oracle, Sybase, SQL Server, DB2, Informix, Ingres, etc are good candidates for the ODBC approach. If anyone is interested in more information about our DB2 driver, send me mail to omri@texaco.com Regards, -- Omri Gazitt NEON Systems, Inc. omri@texaco.com oh yeah, standard disclaimer applies