Re: ODBC

In article <3lqcra$ah6$2@mhade.production.compuserve.com>, Benjamin Taub <74557.3255@CompuServe.COM> writes: |> >>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.<< |> |> I've recently read in the Compuserve DBMS Magazine Forum that |> ODBC does not have the negative effect that everyone says it has. |> I must admit, though, that this is counter intuitive. Because |> the driver is translating generic, ODBC SQL into |> manufacturer-specific SQL, shouldn't there be some overhead here? |> Also, doesn't the ODBC standard also call for certain data |> handling steps when data is returned to the client, once again |> theoretically incurring overhead. Well, if you are using a driver that literally translates ODBC SQL to product specific SQL (which again is compiled into the internal representation) I do not see how you avoid the overhead. But some of the DBMS companies have solved this in a smarter way. They provide a native ODBC interface. Hence, the first SQL-to-SQL translation is not necessary and you get native array fetch protocol support which is MORE efficient than regular SQL fetch. Thus for some product (e.g. the Swedish MIMER) you end up with a better performance. -- Regards, Bo Kahler E-mail: kahler@delab.sintef.no SINTEF DELAB Phone: +47-73-593175 N-7034 Trondheim Fax: +47-73-532586 Norway