RE: SQL under the covers

["Reeve" <news@xxxxxxxxxx>]

I might have messed up my example, and as I think about it more, I really am
trying to peek under the covers at execution time.  In simple terms, I'm
wondering how I debug a complex SQL statement that doesn't work, and I guess
there's no easy way to do it.  Sometimes the SQL error messages make you
think.

If none the CASE statements evaluate as true in this example, no sort is
performed.  This logic works in several of my programs of varying shapes and
sizes; it makes a very cool we-don't-need-no-stinkin'-Windoze
point-and-double-click-to-sort application.  Green-screen folks accustomed
to limited order-of-data choices love it, and from a coding standpoint it's
a lot easier that setting up gobs of logical files.

-rf

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
> Sent: Monday, July 12, 2004 2:43 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: SQL under the covers
> 
> Thanks, Walden, for saying so well what I was trying to say. There IS no
> "generated" statement per se. The stuff is really all done under the
> covers.
> 
> In this case, DBMON showed that the substituted host variables make
> the
> statement look like this for the QRFLD = 'QQQ014'
> 
> select fhpro, fhonm, fhfamt + fhjamt as qnetfee,
> fhsua3
> from frp001
> Order by
> case
>    when 'QQQ104' = 'QQQ104' then fhpro
>    when 'QQQ104' = 'QQQ105' then fhonm
>    when 'QQQ104' = 'QQQ111' then fhsua3
>    else null
> end
> 
> I tried this, using a file I had with different column names. I don't
think
> it sorted - fetched in arrival sequence, AFAIK. Could it be hitting the
> NULL? Is it possible that things don't match because of escalating
literals
> to VARCHAR, so the equality test fails?
> 
> Reeve, does this actually come out in the sorted order for you? I ran this
> on V5R3, not V5R2. I put the statement intoa program I called REEVE
> with a
> single 6-character parameter QRFLD.
> 
> Thanks
> Vern
> 
> 
> At 12:49 PM 7/12/2004, you wrote:
> > >Looking at the generated SQL code (with the SQL includes, SQLCA,
> etc.)
> > >doesn't tell me much.
> >
> >It won't. The generated SQL code isn't used to access the data, it's
> >used to access the SQL engine. The SQL engine is responsible for
> >figuring out how to retrieve that data. You shouldn't see anything in
> >the RPG that "understands" how that SQL is run.
> >
> >The best you can do is run the query in debug, but remember, run the
> >query against production data. The "right" way to retrieve a row from a
> >test table with 50 rows isn't the "right" way to get a row from the same
> >table with 50 million rows.
> >
> >-Walden
> >
> >------------
> >Walden H Leverich III
> >President & CEO
> >Tech Software
> >(516) 627-3800 x11
> >WaldenL@xxxxxxxxxxxxxxx
> >http://www.TechSoftInc.com
> >
> >Quiquid latine dictum sit altum viditur.
> >(Whatever is said in Latin seems profound.)
> 
> 
> --
> 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.