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



I use DDS to define tables because it's easy/easier to set up COLHDG's, SQL
doesn't support edit codes/words (sigh), and CHGPF makes definition changes
painless. Yes, I'm missing out on a few handy functions offered by CREATE
TABLE but having edit codes built in *greatly* improves the quality of user
queries. Otherwise, SQL is the way to go most of the time, especially if
you pay attention to the Index Advisor. I haven't created a LF in
years...but I have created a lot of SQL indexes.

A good example of an exception to the SQL approach is an existing complex
report, written years ago, and with lots of level break-ery: for that, an
input primary is really handy. However, to get ahead of the howls from the
SQL cognoscenti, yes, there are lots of new(er) grouping and subsetting
capabilities which *could* eliminate the need for an IP, level breaks, and
so on. But complex reports are often driven by unusual user requirements
("combine these two divisions", "don't combine these two divisions",
"eliminate this subtotal"--you know what I mean!) and there may be no
economic value of going through a rewrite/refactor.

\reeve

On Mon, Jun 27, 2022 at 11:35 PM LOGIC IT: Karl FRITZ <k.fritz@xxxxxxxx>
wrote:

Frank,

I do not agree with you.

I use LF for reading and PF for updating only, even if I have to read the
PF
a second time.
So I get a clear file handling at all.

Your proposed technique requires to compile the files with lvlchk *no.
Thought, I should mention it.

And each new LF requires maintaining of access paths. Have a lot of fun
restoring a huge file with
50 LF's.

SQL is a great alternative with a lot of possibilities. Personally, I
prefer
the old style, because the use
of data repositories for common redefinitions of fields is not as
complicated as by SQL definitions.
In this case is a DDS definition much more clearer and easier. It's not all
golden at SQL.

But don't misunderstand me, I use both - native I/O and SQL.

Just my 2cts.
kf

-----Ursprüngliche Nachricht-----
Von: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] Im Auftrag von
Frank Kolmann
Gesendet: Dienstag, 28. Juni 2022 06:32
An: rpg400-l@xxxxxxxxxxxxxxxxxx
Betreff: Re: Avoid Level checks was ( Generic RPG File Handler for File I/O
using OA)

I learnt too late, but this is how to avoid level checks.

In RPG programs never ever use PF, only ever use LF. (Perhaps change the
RPG compiler to enforce this?)

It is even possible to retro fit this concept to old code with a bit of
file renaming and recompilation of the PF and related LF.

Then never ever change LF DDS, only create new LF as needed.

To change PF you only ever add fields to the end of the field list, even
if it means data is stored in two fields in the case of field size
extension.

Recompile the PF and related LF and your programs will work fine. The
only programs you need to change is those using the new fields.

Fwiw
Frank


On 27/06/2022 3:19 am, Jon Paris wrote:
"So far I haven't found an example where I can see how to use them for
SQL
CRUD operations. It looks like it works great for RPG file operation
codes."

And you won't find any because that is not what OA was designed to do.
As
I said earlier it was designed purely to allow conventional RPG op-codes to
access devices not directly supported by RPG.


Jon P.

I developed a program to do all this using JSON request/response avoiding
dependency on a file structure. This way If my RFID changes on a file
my
RPG programs will not give level checks:)

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.