RE: QUERY TO SQL

["Dan Bale" <dbale@xxxxxxxxx>]

>I also sense that IBM wants us all to go with SQL, and you
>can get a similar interface to that with STRQM.

But, we've discovered that QM does not handle joins very well.  I agree, IBM
has designated SQL as the present and future.

<RANT /ON>
Well, @#$% it!  Then IBM should upgrade RTVQMQRY so that
it returns equivalent SQL.  End of story!
<RANT /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 Vernon Hamberg
Sent: Tuesday, March 19, 2002 10:05 AM
To: midrange-l@midrange.com
Subject: RE: QUERY TO SQL


Agreed. But it gets worse. What bit you is that Query/400 uses blanks and
zeroes for defaults in the unmatched fields (or DDS DFT values). SQL, which
is the driver behind QMQRY, knows nothing of DDS and other default values.
Its default is NULL - probably an industry standard.

I also sense that IBM wants us all to go with SQL, and you can get a
similar interface to that with STRQM.

It's a mess. OPNQRYF, Query/400, and SQL all use essentially the same
engine down below, and could have the same functionality. They don't.

Of course, interactive SQL understands JOINs but does not have prompting
for them.

At 09:59 AM 3/19/02 -0500, you wrote:
>Sheesh, well I guess you answered my last question!  Would it really be
that
>hard for IBM to "enhance" RTVQMQRY to get the SQL right on joins?  After
>all, isn't WRKQRY using SQL under the covers?
>
>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.)