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



Please, do not go on that path!!!!
You will create a magnitude of different logicals with all kinds of nasty 
record-formats not representing all the fields in the PF record-format.
You get your self in serious problems determining what logical/record-format to 
use when you have to create a new function over the Db....Yeah, the accesspath 
exist. Noooo, the fields needed are not in this record-format!!! What to do???? 
Create a other LF??
I've seen laaaaarge systems with numerous logicals with exact the same 
access-pathbut different records-formats because they had to decide every-time 
'for the sake of not having to recompile and to distribut half of the 
application running in more than 50 countries' to create a new logical on the 
same path but with again an different record-format.
There system would have been a lot nicer/smaller/faster when they had kept them 
self to the 'First lesson of databasedesign'. One PF has One record-format! 
Every LF uses this record-format!
When one PF got more than 10 LF's......You have to determine if your Db design 
is still correct!
 
Eduard.


William Washington III <w.washington3@xxxxxxxxxxxxx> wrote:
Hey! Now THAT is kewl! Seriously! And it makes perfect sense, because the
view has all of the info that particular program needs. Another program would
use a different view. I see no need to ever change a particular view, unless,
once again, someone went to extremes with creating them.

I'll put that info to use immediately! Thanks, Chris.

William


> date: Tue, 8 Mar 2005 15:19:07 -0800 
> from: Chris Bipes 
> subject: RE: Logical File or OPNQRYF or any other way ? - Legacy
> 
> Actually if you create views to use with your RPG program that do not share
> the view of the PF, you can add or move fields in the PF and not effect any
> RPG programs using the other views. Now if you remove a field used by SQL
> or RPG you will have problems until you update your programs not to use that
> field. It will also cause problems with your defined views. Think of a LF
> that has it's own record format, not using the PF record format as a view.
> 
> Now how does that differ from imbedded SQL except in flexibility of creating
> the view on the fly.
> 
> Chris Bipes
> 
> 
> -----Original Message-----
> If I make a change to the database, yes, I will have to modify (typically,
> recompile) my RPG programs. So what? That's part of the process. The fact
> that the database is bound to the program gives RPG its well-deserved
> reputation for random-access performance. That is the design tradeoff for a
> business machine. If the data layouts are changing all the time, well, what
> kind of model is the business operation on?
> 
> 

-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.