We have an application that allows users to extract a subset of order-entryAs others have mentioned, the idea here is to create a "batch number" field that corresponds to the member name. If you really want to keep things clean from a program standpoint, you can then create a view over that batch number; your program will only see those records.
data (ORDER_HDR, ORDER_DTL, etc.) into uniquely-named members. Once cloned,
users are able to manipulate their temporary copy of the data as necessary,
running 'what-if' scenarios, etc. in their own private sandbox without
affecting the production data. When finished with a batch, the user can save
their work in the temp member, append it production, jump to another member,
etc. Since the members are in the same files they all share record formats,
indexes, RPGs, queries, *AUTLs and journals. Nice and tidy.
If this app is switched to SQL we'll have to abandon the multi-memberYup. Multi-member files, at least in the DB2 sense, are not compatible with the DDL approach.
concept and I'm having difficulty visualizing the 'SQL way'. Partitioned
tables aren't appropriate in this case because the separation really isn't
based on a range or hash. Creating temporary libraries brings up its own set
of issues with *LIBL and security.
I suppose one could design a system with two sets of tables
(ORDER_HDR/ORDER_DTL) and (ORDER_HDR_T/OREDR_DTL_T), prefixing each row with
a key (a.k.a. "member") that each program would filter on. It seems like
extra overhead, but maybe that's because I'm looking at things from a DDS
This mailing list archive is Copyright 1997-2013 by MIDRANGE dot 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 here. If you have questions about this, please contact