RE: trigger program: can I fool a program into reading some selectfi elds from another file?

He's not planning to update any data files, just the fields in the program
that caused the read.  (as I understand the problem.) 
  
 
---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: Midrange Systems Technical Discussion
Date: Tuesday, October 14, 2003 11:50:51
To: Midrange Systems Technical Discussion
Subject: RE: trigger program: can I fool a program into reading some
selectfi elds from another file?
 
Rob, join would work fine and I've done this. The problem definition was
how to READ the existing Item Master but get the data from a common
Corporate master file (for select fields). Of course, the update of Item
Master will have to be changed in any event (to cross-link the various
Division Item Numbers to Corporate record) and could NOT be done through the
join *LF. (No biggie.) I would hafta assume there would be a new pgm to
update this corporate-level Item Master. (See below, if you wanna.)
 
| -----Original Message-----
| [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of rob@xxxxxxxxx
| Sent: Monday, October 13, 2003 6:58 PM
 
| Join won't work.
|
| Any programs that update the old file will croak. Join's are not
| updatable.
|
 
| Scott Klement <klemscot@xxxxxxxxxxxx>
| 10/13/2003 03:59 PM
 
| Subject
| Re: trigger program: can I fool a program into reading some
| select fi elds
| from another file?
 
| Unless I'm mistaken, you can do this with a join logical file...
|
| Rename the old customer file, build a join logical over it and the new
| customer file so that it pulls the address from one, and the remainder of
| the data from the other...
 
 
| -----Original Message-----
| [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of
| rick.baird@xxxxxxxxxxxxxxx
| Sent: Monday, October 13, 2003 6:04 PM
 
| I would then lock down maintenance of these fields at the
| satellite level,
| because any work done there would be superflous, unproductive and
| probably
| downright frustrating for anyone trying to change the fields :)
 
I prefer Rick's solution, in addition for reasons stated, because a join
would be two reads for each access to Item record. You'll be reading MANY
times more than you'd update.
 
The bigger challenge is not technical: WHICH fields will be assigned to the
Corporate Item Master?? Just the description and dimensions? (And who IS
gonna control this, then??) Are Items single-sourced from one Vendor
throughout the Enterprise? Does each Division haggle it's own PRICE, or is
there gonna be some effort to get best price?? Do you currently (or plan
to) transfer inventory from one Division to another to meet market
demand...? Etc, etc...
 
 
_______________________________________________
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.
 
.