|
Dan: On Tue, 19 March 2002, "Dan Bale" wrote: > 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. Perhaps, but the RTVQMQRY isn't really designed to handle *QRYDFN objects... it should use *QMQRY objects as the source. IBM managed to get it to work with *QRYDFN objects as well. However, a compiled *QRYDFN can include more than just structured query statements. Compiled *QRYDFNs are close to being 'programs'. It's easily conceivable that there is no appropriate SQL for some Query/400 constructs. That's not to say that JOINs aren't handled poorly, but I suspect that's primarily because RTVQMQRY hasn't been updated significantly since SQL JOINs became as advanced as they are now. And I suspect that's simply because there aren't enough sites asking for it. Tom Liotta -- Tom Liotta The PowerTech Group, Inc. 19426 68th Avenue South Kent, WA 98032 Phone 253-872-7788 Fax 253-872-7904 http://www.400Security.com ___________________________________________________ The ALL NEW CS2000 from CompuServe Better! Faster! More Powerful! 250 FREE hours! Sign-on Now! http://www.compuserve.com/trycsrv/cs2000/webmail/
As an Amazon Associate we earn from qualifying purchases.
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.