|
midrange.com
Just starting out, I don't want to form any bad habits or practices in my
code. So thank you for giving me the constructive insight on OVRDBF and
logical files. After reading the replies READE is obviously a better
choice. I wish there was a book out there with opinions and insight on the
better ways to approach the coding of a project or program. Or something to
the effect of "Only code it using this approach if ......." My biggest
fear is coding myself into a corner so to speak and then having to do a huge
overhaul of a bunch of programs because initially I didn't choose the best
way to go about things.
Well enough said.
Thanks Again,
LAC
-----Original Message-----
From: Jim Langston [mailto:jlangston@conexfreight.com]
Sent: Thursday, June 08, 2000 4:20 PM
To: RPG400-L@midrange.com
Subject: Re: F Specs on an OVRDBF
Denis is right, but on the note of what do your F-Specs need
to look like?
Your F-Specs do not really need to change at all. The logic
in your program
may need to change if it is a different type of key, but if
it is the same key read
in both files, your RPG program will have no idea if it's
reading a physical file
or a logical file. They both look exactly the same to the
RPG program, and you
treat them exactly the same way. That is the magic of
OVRDBF and logicals.
Regards,
Jim Langston
Denis Robitaille wrote:
> You can do it with OVRDBF but I would not. But first, let
supposed that you do go the OVRDBF way.
>
> Lets say that your logical are named P701L1 and P701L2. In
your F spec use P701L1 and in your CL
> you use one of the 2 following override depending on which
vendor you want to access:
> OVRDBF (P701L1) to (P701L1)
> or
> OVRDBF (P701L1) to (P701L2)
>
> That will work.
>
> But then again, I think that this is a bad way to solve
this problem. What if you add another vendor, you will have to had a new
logical and you will have to modify the CL. And what if you change a vendor
number ...
>
> A better approach would be:
>
> - create one logical file (lets call it P701L1) with the
key made of the vendor number and the product number next.
> - then you pass as a parameter to your RPG program the
vendor number that you want to work with.
> - In the RPG program, use the READE opcode instead of the
READ opcode (look up the manual, you will understand the difference) to
extract record from the P701L1 file
>
> This way, you will need just one logical file regardless
of the number of vendor and this way, any change in the number of vendor or
their id will have no impact on the CL or RPG program
>
> Hope this help.
>
> Denis Robitaille
> Directeur services techniques
> Cascades Inc
> 819 363 5187
> fax 819 363 5177
>
> >>> LCobb@PapaGinos.com 06/08/00 02:25pm >>>
>
> Salutations,
>
> I have a product master file (P701). I had to write the
online maintenance
> in such a way that when the DP clerk selects product
maintenance they are
> prompted as to which vendor they wish to do maintenance
on. So only those
> products with that particular vendor code are accessible
through
> maintenance. I created two logicals utilizing the select.
One for each
> vendor.
> I know I can do it with BLDQRYSLT, but I prefer to try to
utilize OVRDBF in
> my CLP. I have only been programming for a year. I am
self taught and I
> want to get a better grasp on this OVRDBF. My boss allows
me to learn
> everything I can, to try new approaches whenever possible,
and get exposure
> on all that RPG, CL, and SQL has to offer. (RPGIV is
coming soon). That is
> why I am choosing OVRDBF (if it is possible).
> My question is (because my boss is on vacation) what do my
Fspecs need to
> look like? I have looked in all the manuals and
infoseeker but I can't find
> this info.
> I am thinking my CL should be:
> OVRDBF (PFILE) TO (VENDOR CODE SPECIFIC LFILE)
>
> Should my Fspecs contain only the PFILE (update) or do I
need the
> LFILE's(input) in there also?
>
> Am I even close with this? Am I wrong in thinking that it
can be done this
> way?
>
> Thank you in advance for any info or insight you can shed
on this matter.
>
> LAC
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to
RPG400-L@midrange.com.
> | To subscribe to this list send email to
RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to
RPG400-L@midrange.com.
> | To subscribe to this list send email to
RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to
RPG400-L@midrange.com.
| To subscribe to this list send email to
RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to
RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
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.
