RE: Accessing files In QTEMP and the utility of multi-member file s

[booth@xxxxxxxxxxxx]

Multi-member is just a disaster waiting to hurt you.  The next good 
application for multi-member files will be the first good application for 
multi-member files.


_______________________
Booth Martin
Booth@MartinVT.com
http://www.MartinVT.com
_______________________




Joel Fritz <JFritz@sharperimage.com>
Sent by: owner-rpg400-l@midrange.com
10/19/2000 12:00 PM
Please respond to RPG400-L

 
        To:     "'RPG400-L@midrange.com'" <RPG400-L@midrange.com>
        cc: 
        Subject:        RE: Accessing files In QTEMP and the utility of 
multi-member file s

Agreed.  Multi member files are much better for ephemeral data contained 
in
one file, or the situation where you want to retain the results from each
step in a process until you're sure you're done where each step depends on
the results of the previous step. 

> -----Original Message-----
> From: Buck Calabro [mailto:buck.calabro@aptissoftware.com]
> Sent: Thursday, October 19, 2000 6:34 AM
> To: rpg400-l@midrange.com
> Subject: RE: Accessing files In QTEMP
> 
> 
> Joel Fritz wrote:
> 
> >OTOH, if you don't have any SQL 
> >tools available except QMQRY, and 
> >all your database work has to be 
> >done in RPG, the only problem is 
> >keeping the file overrides and 
> >logical members straight.
> 
> I have great experience with multi-membered files, and I respectfully
> disagree.  The greatest of all the multi-member problems is 
> that the record
> does not know who it "belongs to."  The member knows.  Take 
> the example
> where the member segregates data by user.  You can't readily 
> run an RPG
> program over one of the members and tell what user the 
> records are for.
> Sure, you can use the INFDS to get the member name, but it gets worse.
> 
> Imagine that your user IDs are 'intelligent' - they somehow 
> have the user's
> location embedded, say CHIBUCK,  NYCJOEL.  Run a report 
> including records
> from all the users in NYC.  This situation is contrived, but 
> it is really
> bad when you keep financials separated by member; JAN, FEB, 
> MAR or Q11998,
> Q21998 or FY1998, FY1999, etc.  Running a report that crosses 
> members is not
> fun, especially when you have to select a subset of those members.

/***********   SNIP *****************/
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: 
david@midrange.com
+---




+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---