RE: SQL vs. traditional I/O?

On Thu, 22 Jul 2004, Joe Pluta wrote:

> c                   for       x = 1 to count
> c                   eval      mykey = %char(count)
> c/EXEC SQL declare c cursor for select * from j4pp1 where key1 = :mykey
> c/END-EXEC
> c/EXEC SQL open c
> c/END-EXEC
> c/EXEC SQL fetch from c into :j4pp1
> c/END-EXEC
> c/EXEC SQL close c
> c/END-EXEC
> c                   enddo

Can this be restructured in such a way that it doesn't required opening
and closing the cursor for every iteration through the loop?  That seems
awful wasteful and could be responsible for a large amount of the
performance difference.  Maybe SQL is still slower, but it seems like this
opening/closing of the cursor needs to be removed from the loop in order
to make an appropriate comparison.  If they can't be removed, this seems
like another example of the shortcomings of the way SQL is used within RPG
more than a problem with SQL itself.

It is also interesting to consider the differences between SQL and RPG I/O
for single record access.  For example, when exactly is the file pointer
set for the chain operation?  If another chain immediately follows that
fetches the next sequential record, is the file pointer reset before
reading the file, or does the system know that it is already set to the
right spot and just leaves it alone?  What about SQL and the same
situation?  Does setting the file pointer even take enough time to be
significant over a large number of iterations?

To me another really interesting question is how does RPG with embedded
SQL stack up against other SQL implementations?  A huge number of other
variables would of course get introduced into this kind of comparison so
it may be pointless.

> It's good to at least hear you say that SQL is not good for some things.
> Later on in our self-help program you'll learn how to say Java is not
> good for all things, and eventually, you'll even learn to say that
> Windows is not good for everything.

Heck, I've been telling people for a long time that Windows is good for
nothing.

James Rich

Vs lbh cynl n Zvpebfsg PQ  onpxjneqf, lbh pna urne fngnavp zrffntrf. Ohg
rira jbefr, vs lbh cynl vg sbejneq, vg vafgnyyf gurve fbsgjner!
        -- Fcbgvphf ba /.