RE: RE: Populating fields based on field name in a file

I've got it mostly working like I want using embedded SQL, what may ahve gotten 
lsot in this is that there will be 1 SKU Master file across all 
divisions/companies (our environments) that will be used to "Pre-Populate" 
fields in a set of 7 files where each environment has there own set (i.e. there 
is an INVMST file for US, 1 for Canada etc.)
 
The user after setting up a SKU in the SKU Master then has a program they can 
go into and select a SKU and it will based on the Rules file pre-populate 
fields in the designated environment file/field with a specific value. before 
calling our packages regualr SKU maintenance stream
This is being done so that some sort of SKU synchronization (for any new SKU's 
added) will exist across environments (i.e. SKU=12345) will have (until the 
user changes it) the same values for a specific field.
 
Example: Rules file says that if the SKU Master Gender Code="UNI" then the 
Merchandise Group # in the INVMST file = 999
 
so if SKU 12345 has a Gender Code of UNI then selecting it to create the SKU in 
the US environment would populate the INVMST file  in the US environment so 
that the IFINLN (Merchandise Group #) is set to 999. 
 
Thanks for everyones help.......


qsrvbas@xxxxxxxxxxxx wrote:
rpg400-l-request@xxxxxxxxxxxx wrote:

> 3. RE: Populating fields based on field name in a file (Joe Pluta)
>
>> And I'd still be interested in a good way to do it in RPG without SQL.
>
>And putting aside the fact that this is not what was asked for, I'd be
>interested in a business application that needs it. I'm hard-pressed to
>think of a situation where the same event can update one of two
>completely arbitrary fields (and user-defined) fields based on the
>setting of a third. Other than some sort of really ugly code-generator,
>I just can't think of the need.

I certainly agree with this. I.e., a business app should know its files, 
fields, etc., and provide the controlled interfaces for managing them. When it 
gets to the point of comparing unknown fields (or more accurately allowing the 
user to select fields from a large set) to unknown values in unknown files 
(selected from a set of files), there seems no business point to it.

Why create such a function? -- Especially when SQL exists.

Tom Liotta