RE: QUERY TO SQL

Sorry for the confusion, Buck.  O.k., so you've known about the documented
limitations.  Don't you find it disconcerting that IBM makes you do this?  I
do.  I'm sure there are valid reasons why your RTVDDSSRC can't replicate
exactly the DDS source that the file object was compiled with.  So what's
IBM's excuse?  They know the internals of the *QRYDFN object.  Heck, it
appears that, with enough work, one could print a query definition and
create the correct matching SQL just from that.  Maybe even create a
template so that it could be done with any query.

<BROKEN RECORD /ON>
The thing that really puts a crick in my jaw is that if IBM truly wants to
move us to SQL, they shouldn't saddle us with half-finished tool called
RTVQMQRY.  Guess it follows the same track record they have for the SQLRPG
precompiler, eh?
<BROKEN RECORD /OFF>

Dan Bale
SAMSA, Inc.
989-790-0507
DBale@SAMSA.com <mailto:DBale@SAMSA.com>
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)


-----Original Message-----
From: midrange-l-admin@midrange.com
[mailto:midrange-l-admin@midrange.com]On Behalf Of Buck Calabro
Sent: Tuesday, March 19, 2002 11:59 AM
To: midrange-l@midrange.com
Subject: RE: QUERY TO SQL


Dan Bale wrote:

>First, the accusation is based on WRKQRY
>*QRYDFN objects being converted to QM via
>RTVQMQRY.  The complaint I expressed is
>with the way RTVQMQRY converts to SQL,
>not necessarily QM itself.

Ah.  That makes sense.  I was afraid I'd left a bunch of QMQRY timebombs in
my code.

>Buck, have you had no problems converting
>queries with joins?

Sure, but that's been documented so long I take it for granted.  I expect
that I will need to re-work converted queries.  I look at it in much the
same way I look at my home-grown RTVDDSSRC; the output is a starting place,
not the end-result.
  --buck