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