Re: Advice needed on a multimember DDS file to be converted to DDL

At 12:51 2008-04-25 -0400, Jeff Crosby wrote asking for
advice about a pair (order header, order detail) of
multi-member physical files. There have been many
responses. Please let me join the party with a few
thoughts.

Jeff writes "OTOH I don't want a kludge." Me neither.
Still, that hasn't stopped me in the past <grin />.

I wonder, Jeff, what your ideal solution would look like?
Do you positively want to use embedded SQL? Or did you
mention it just as one way to select records with a
particular value of field MEMBER? Would the continued
presence of OVRDBF or OPNQRYF commands in the wrapper CL
programs be a kludge, in your opinion? Would the very
existence of wrapper CL programs be a kludge?

If I understand Jeff's thoughts correctly, the proposed
field MEMBER is being asked to do three (please pardon the
pun) distinguishable jobs.
(*) Field MEMBER distinguishes one incoming order from the
other incoming orders.
(*) Field MEMBER distinguishes incoming orders from the
accepted or otherwise "real" orders.
(*) Field MEMBER distinguishes today's orders from orders
for later shipment.
That is rather a lot to ask of one field.

The second distinction can be handled by a new pair of
physical files to hold the incoming orders. This may be a
natural thing to do if your business has the notion of
"accepting" an order and if the acceptance happens at this
time. Anyway, it may still be convenient at the programming
level. It may then be easier to invent other mechanisms for
the other two distinctions.

Lots of other points in the ensuing discussion caught my
attention, but I think it best to save my comments until
Jeff gives some indication of the direction of his interest.

In summary, I think it unlikely that any solution will be
entirely without kludge. But one can reasonably hope to
minimize the places where kludginess is manifest.

HTH,
Terry,
rent-a-geek and database bithead.