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

> From: Tom Liotta
> 
> 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.

Again, I don't think this is the business requirement.  The business
requirement is a DATABASE-DRIVEN choice of updates.  It's not an ad hoc
selection by a user (for which SQL excels), but instead a finite set of
options based on switches in the database.  This is perhaps the very
definition of what a procedural language is best at, and what RPG's
native I/O capabilities are built for.

Now, the original question had 50 control fields and perhaps 200
different database fields.  At that point, the business decision of
whether to do this in SQL or RPG might depend more on maintenance of
that program, but again if this were something that was rarely
maintained, the one-time cost and irregular fixes of the program would
be offset by the performance gains.  On the other hand, if the switches
were changed with some regularity it might then make sense to have a
generator that builds the program.

In any case, it really depends on whether your time as a programmer to
build the application is more valuable than the total time lost over the
many times the end user is going to use your program.

Joe