Re: ODBC is Slow!!??

In article <39okdp$g25_at_sndsu1.sinet.slb.com> amikam_at_norcross.mcs.slb.com (Leor Amikam) writes:
>I am trying to configure SQL*Net v2.0 for Windows on a Windows client
>running FTP Software's PC/TCP v2.3. I wrote an ODBC client program to do
>1000 INSERTs into a 16 SMALLINT column table. The thing only averaged about
>2 INSERTS/Second! I tweeked the network settings of PC/TCP and that didn't
>make that much difference.
 

>My questions are these: (1) Is this normal speed for Oracle? and (2) Does
>anyone have any information that they've compiled about benchmark speeds for
>Windows clients?

How is your client written? Do you call the ODBC API functions directly? Many folks think "ODBC" is slow when, in fact, it is a problem with the way they are "getting to" ODBC.

For example, if your client is written in Visual Basic and you use the Data Control provided by Microsoft, then you are NOT really using ODBC directly, but instead are passing through an "engine" which is really Microsoft Access (and an older version at that) before you get to ODBC itself. A paper in Microsoft's Knowledge base ("Advanced Data Access Using Visual Basic 3.0 and ODBC", Tech*Ed 1994) compares direct access to the ODBC API and through the MS Access engine and comes up with anywhere from a 2x to an order of magnitude difference between the two methods. Although I haven't benchmarked anything fomally, this jibes with what I've seen in some of the in-house applications we've developed. Others in our company report similar (or worse) when the client is Microsoft Access itself.

Beyond that, which ODBC driver are you using? The Oracle 6 driver provided by Microsoft, though adequate, is no speed demon (OTOH it IS free - higher performance drivers from others cost $99 per seat, more or less - depends on the quantity, which is an even more important consideration if you're rolling out an application to hundreds or thousands of in-house users rather than recovering the cost through the price of a retail project).

In summary, ODBC per se is not necessarily slow.

--
Bill Meahan,  Senior Developer  |        wmeahan_at_ef0424.efhd.ford.com 
Electrical & Fuel Handling Division, Ford Motor Company
Opions expressed herein are those of the author and in no way represent
any official statement or opinion of Ford Motor Company