Re: Performance of ODBC vs. other access methods

[Nathan Andelin <nandelin@xxxxxxxxx>]

I haven't looked  at the latest data access components in .Net or Java, and I'm 
not sure what  protocols they might be using  for data interchange with the 
server, but it  wouldn't surprise me if the underlying driver in all cases was 
an ODBC driver  (one using the ODBC protocol), though default configuration 
settings (connection pooling, SSL flag, data compression flag, etc.) might be  
different from one component to the next.
 
Nathan.
  
 
----- Original Message ----
From: Dave Odom <Dave.Odom@xxxxxxxxxxxx>
To: web400@xxxxxxxxxxxx
Sent: Thursday, August 31, 2006 12:23:22 PM
Subject: Re: [WEB400] Performance of ODBC vs. other access methods

Nathan,

Thanks for the info.   I, too, have found certain implementations of
ODBC fairly efficient in tools like QMF for Windows when talking to
non-DRDA machines, but when using tools like Crystal Reports and its
implementation of ODBC, my CPU goes out of site.  So, in the case of
vendor's tools it does depend on how they implement ODBC and the rest of
their processes.   

> From what I've been able to experience and glean from others so far
when building remote access apps or tools the following are the best
performing access methods:

- Have your app call System i5 apps written in some native compiled
language with imbedded SQL therefore creating static SQL   -  Best
access
- App calls application APIs stored on the i5 written in a high-level
language
- App calls REXX application that calls SQL or application stored
procedures 
- App calls SQL or application stored procedures using the IBM .NET or
the Java "provider"
- App calls SQL or application stored procedures using the older OLE
provider 
- App calls SQL or application stored procedures using ODBC provider
- App sends SQL strings through the above "providers" using the same
order of preference as above

Something like that.   I'm sure you all will put in your opinions as to
my list.    I'd also like to hear about the basic premise that ODBC is a
slow performer/"provider" compared to OLE,  the IBM .NET provider or the
Java provider and certainly slower than calling stored procedures or
native language APIs.

Thanks,

Dave