Neither has an advantage. They are two very different types of things used for different kinds of reasons.
OVRDBF allows you to substitute one file in place of another file at run-time.
Different LFs allow you to use different views or indexes over the same physical file usually at compile-time.
As Tom mentioned, Both OVRDBF & LF are having their own advantages,
If you would like to create a view in runtime, you can use OPNQRYF command.
So many questions, so little time.
Have you done any research before you ask?
Add embedded SQL, embedded dynamic SQL, SQL views to the mix.
And consider OVRDBF with OPNQRYF
Organizational standards and simplicity and flexibility of code all go into the mix
Yes both can be used. But you seem confused.
The OVRDBF is used to present a different file (or member) to the RPG program.
A logical file delivers the records in a different sequence and or by different selection rules.
The rpg program will generally fail if
- the file presented to it has a different structure (Recocd Format)
- the file presented has a different key structure and is used by the RPG program.
why we can use both operation OVRDBF and LF….
The two are different. They don’t do the same things; they don’t directly conflict with each other.
OVRDBF and LF, the both operation retrieve record using Physical file access path, or different access path????
both operation retrieve record using Physical file access path, or different access path????
Neither. Those don’t retrieve records. They determine where records will be retrieved from.
OVRDBF determines that the records will be retrieved through an access path for the file named in the TOFILE() parameter. The file that is overridden to can be a different PF or it can be a LF over the original file or over a different PF. The file that is overridden from can be a PF or a LF.
The access path for an LF will be used to retrieve records when a LF is opened.
In both cases, the access path might be the same as a PF or different. Access paths can be ‘shared’ between files. It’s often best to arrange files so that access paths are shared. Any access path that is shared will necessarily always be over records from the same PF (or PFs, in the case of joins or unions such as a multi-format LF).