×
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 Justin,
I'm coming from a RLA perspective because the new RPG Redbook that
prompted this discussion used RLA, and I think most people would agree
that RLA is the dominant I/O method for RPG.
using SQL it's more easy to decouple database and application - but it could
be done in RLA too: never use a PF only LFs!
I haven't given a whole of thought on this from a SQL perspective. My
understanding is that the pre-compiler pulls in the column definitions,
kind of like RLA record formats. Of course, with SQL you would only bring
in the columns you
need so you might be OK if a non-referenced column was changed. I'm not
sure a single *SRVPGM could handle all the I/O using SQL since most
programs will have specific WHERE's and/or JOIN's.
the key to success is: never use tables in your application, only use it
defining Views. So your physical implementation of your database is hidden
from your application. You could change the implementation of your database
as long as you could provide the same views with the same capabilities - and
using instead triggers, you could even update nearly any view, even if the
contain join operations. Your SRVPGM would use the extended view with all
fields and you would have setters and getters only providing/needing a
subset of data. There would be only one Module using this view, all other
programms are using this SRVPGM to retrieve and manipulate the underlaying
data.
And how did this end up on the Midrange list?
this is very easy done: just typing in the wrong eMail adress :))
Dieter
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.