× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 
 

nandelin@xxxxxxxxx 8/31/2006 09:17:53 >>>
ODBC itself is fairly efficient, and is quite a bit more efficient than
SOAP and XML based data interchange, but when you open a server for
remote access via ODBC you never know what type (perhaps even malicious)
or amount of workload will be generated by ODBC clients, and it's hard
to manage.

It puts the responsibility for managing workload and performance into
the hands of end users, and the tools they choose.

Nathan.



----- Original Message ----
From: Dave Odom <Dave.Odom@xxxxxxxxxxxx>
To: web400@xxxxxxxxxxxx 
Sent: Wednesday, August 30, 2006 5:53:29 PM
Subject: [WEB400] Performance of ODBC vs. other access methods

What's the prevailing wisdom backed up by real world experience when
using ODBC from whatever tool or programming language to access
DB2/400
or ORACLE versus using some other remote or distributed access method
such as DRDA, calls to stored procedures or API calls?   I've been
told
that ODBC is a good performer but have my doubts.

What's your experience show vs Ivory Tower tests?

Thanks in advance,

Dave

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.