Re: SQL help

["Richard B Baird" <rbaird@xxxxxxxxxxxxxxxxxxxxx>]

Rob,

Yes, it is traditional.  I've always done it that way.  I don't however
think it is better processing the job message queue.  If all you are doing
is processing messages, the logic might be simpler, but much less
intuitive.

Checking a field for validity with a setll or chain is very intuitive.
calling some api or some kind of message processing routine isn't.  If you
mix the methods, it would become even less understandable.

a new programmer coming in to such a system might get the wrong idea that
no RI need be done by hand.  or, if they don't completely understand your
message routines, that none IS being done.  This is a little scary to me.

now, outside the box, if I had it all to do over again, starting on a clean
sheet of paper, I might consider doing all field RI checking that way, but
maintaining and adding to legacy stuff, the db RI is just an extra check on
what I do programmatically.  I'm in the box.

Rick

---original message---
But you are using traditional logic.  Traditional logic says to verify
each field yourself.  For example if you are entering an item number with
an item class then verify that the item class exists.  However, 'thinking
outside the box' says that if you have the RI constraints in place you can
just write the item record and interpret any messages you get.  After all,
why duplicate the logic that is already in place for your RI and/or
triggers?  Sooner or later some clod will update the data from outside the
one 5250 program you think is the only method to update the file.  A
program this way should be more efficient.  You wouldn't have to read all
the upper level files yourself.  Your program logic would be much simpler.
 And it will be easier to convert from one method of presentation to
another.

Rob Berendt
--