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



Hi Frank,

Just wanted to point out, it's never too late...

Given 1000's of RPG programs with
- the PF defined on a f-spec.
- LF (w/o column list) on the f-spec

All you need to do..
- create a new PF with a new name (optionally use SQL DDL)
- copy data from old PF to new
- create a LF (with column list) that has the name of the original PF
- modify existing LF/indexes to have column list & re-create*

Done properly, you don't have to recompile any RPG programs.

Now you have a PF (or table) you can add columns too without needing to
recompile any RPG programs.

Just remember going forward if using RPG RLA,
- never specify the new PF on the f-spec.
- always list columns on LF/view/indexes*

*note if creating a SQL index, use the ADD <column name1, column name2>
syntax to include specific columns if you plan to use the for RPG RLA (or
just in case)

Charles


On Sat, Aug 15, 2020 at 5:47 PM Frank Kolmann <frank.kolmann@xxxxxxxxx>
wrote:

Hello Dieter

Yes I understand the power of SQL. In my last 5 years I learnt a lot
about SQL and totally agree with you.
In SQL I learnt enough to be able to do in one statement what I needed
an entire RPG program to do AND to do it understandably, SQL can get as
convoluted as C sometimes.

However there is a lot of RPG RLA about.
If only I had truly understood to
NEVER EVER use PF in RPG, use ONLY LF.
NEVER Ever allow LF to be defined without fields.
Never Ever change a LF, instead create a new LF if a change is needed.
Never Ever change a PF field attribute, instead create a new field at
the end of the list of fields.

This is nowhere near the power of SQL, but it would have been a step in
the right direction, to decouple program logic from database structure.

I con only see the value of such a process in hindsight, I was too
stupid to understand when I was young.
It would have made my life a lot simpler, and my productivity double or
more.
I was almost at a standstill at the end because I was so wary and
fearful of database changes.

With SQL you still need an administrator who knows enough to check that
the appropriate indexes exist, SQL tells you this in the log
information it provides. Small price to pay.

Regards
Frank

Regards
Frank

On 15/08/2020 10:11 pm, D*B wrote:
<Frank>
WOW. So simple. After 30 years of RPG coding the PF trick NEVER
occurred to me. WOW only ever use lgl files. KISS, I am so stupid.
</Frank>

If you succeed to avoid RLA (SQL only access), you could enhance
decoupling database implementation and programms. Using view only
access, your programms don't need to know anything of your index
design, you would use select * and fetch into external DS and update
insert without fieldlists everywhere, with instead triggers you could
even move fields around from one table to another. That's the real
power of SQL (and not SQL DDL versus DDS or index size or which query
engine is used or performance).

D*B

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