× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dan, I spot several meanderings here.

1)  RTVDDSSRC
a)  What does that have to do with *QRYDFN's?
b)  There is a tool in Op's Nav called 'Generate SQL' which will give you
the sql to recreate the file.  Also, if you just want to add a field or
something you can do it there.

2) RTVQMQRY
As someone suggested - submit a design change request, don't preach to the
choir
http://www-912.ibm.com/s_dir/slkbase.nsf/1ac66549a21402188625680b0002037e/3ca7d5dfc681aa86862565c500526323?OpenDocument&Highlight=0,5314847


Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin



                    "Dan Bale"
                    <dbale@samsa.com>         To:     <midrange-l@midrange.com>
                    Sent by:                  cc:
                    midrange-l-admin@mi       Fax to:
                    drange.com                Subject:     RE: QUERY TO SQL


                    03/19/2002 12:15 PM
                    Please respond to
                    midrange-l






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

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.







As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.