Re: Performance of ODBC vs. other access methods

Crystal Reports is one of the absolute worst implementers of ODBC to any 
platform. It is really hard to make it work well, although I had some success 
by forcing it to use exactly the SELECT statement I wanted it to - I forget 
where I did that - some builder window, as I recall. This is not a problem with 
ODBC on the iSeries, it is a problem with Crystal. They assume a worst-common 
denominator kind of operation.

BTW, the COMMON presentation is some of the same information as the other links 
I gave you - getting an IBM user and password is no sweat, however, there 
should have been a link to get one.

Vern

-------------- Original message -------------- 
From: "Dave Odom" <Dave.Odom@xxxxxxxxxxxx> 

Nathan, Vern, et al, 

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 sight. 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 - Worst of these possibilities 

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 

-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list 
To post a message email: MIDRANGE-L@xxxxxxxxxxxx 
To subscribe, unsubscribe, or change list options, 
visit: http://lists.midrange.com/mailman/listinfo/midrange-l 
or email: MIDRANGE-L-request@xxxxxxxxxxxx 
Before posting, please take a moment to review the archives 
at http://archive.midrange.com/midrange-l.