Re: embedded SQL Precompiler

Phil,

The results are about the same. The CLI APIs used to
be very flaky, but lately they have gotten much better.
I use a single SQLRPGLE module to process SQL
statements. I wrote it to fit the 98% case. It has worked
basically untouched since V4R2. If Rochester decides
to end enhancement, it is only going to be a problem for
the 2% case.

The technique that Rochester used to support SQL is
flawed and you would be better off isolating yourself
from their implementation. In my case I have a single
module to change if the underlying support changes.
Here is a link to the source for that module:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/iseries-toolkit/CVSROOT/src/qrpglesrc/dynsql.sir?rev=HEAD&content-type=text/vnd.viewcvs-markup


The most important part is to modularize your code
so that don't have a bunch of SQLRPGLE modules. One
module with a dozen procedures should be able to
support the SQL needs of pretty much anyone. That way
you are insulated from the whims of Rochester and are
in a position to take advantage of enhancements, which
is much more valuable than a few CPU cycles.

David Morris

>>> sublime78ska@yahoo.com 02/20/02 08:01AM >>>
>
> ALL Enhancements to the DB will be in SQL.  UDF's
> UDT's, EVI's, Blobs,
> Clobs, DataLinks, etc
>
> And they don't put their money where their mouth is.
>
> NO new enhancements to the Native DB access
> methods(ie Chains, Reads, Etc)
> All enhancements would be taken advantage of by SQL,
>
> BUT They are giving lip service to helping us REALLY
> USE the new
> enhancements.
>

Maybe they want us to use the new support in RPG to
call java, and use jdbc.  :-)

The point of my question, though, is Does it buy me
anything to use the api's or is the result the same?
It looks like the api's actually could produce slower
performance.

Phil