Re: Performance of ODBC vs. other access methods

[vhamberg@xxxxxxxxxxx]

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.