× 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.



Darryl,

Surely you can see why it does this? You used OVRDBF to point to member B -- this is basically saying to the OS "ignore what the program specifies. Override it's logic, and access member B"

So it should be no surprise that your SELECT reads member B instead of A.

It's unclear as to why you're doing this OVRDBF to member B. You say that you're using a select over an alias to sum up member A. Great. So, what are you doing with member B? I see Buck guessed that you are using an F-spec that's accessing member B -- but I don't see anything in your message that says so.

If you're using SQL to access member B, consider using an alias (just like you are for member A) instead of the OVRDBF.

If you're using F-specs, consider using the EXTMBR() F-spec keyword to specify the member you want instead of OVRDBF. EXTMBR will only apply to that F-spec, whereas OVRDBF applies to everything within it's override scope.

-SK


On 9/18/2013 11:54 AM, Darryl Freinkel wrote:
I have a program that reads File_A which has multiple members.



There is a CL program before the SQLRPGLE program that does a OVRDBF FILE_A
to member B. In the program, I use a SQL SELECT to total up the balance on
an invoice which is SUMed against member A.



I create an ALIAS - CREATE ALIAS QTEMP/FILE_A_A for LIB/FILE_A(A) in the RPG
program.



In the program, I do a SELECT sum(AMT) from QTEMP/FILE_A_A.



Problem:

When the OVRDBF is used, the SELECT does not find the records. It seems to
be looking at member B in File_A.

When I remove the OVRDBF, the SELCT works as designed.



Does anyone know what the problem is and how to work around the issue?



TIA



Darryl Freinkel.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.