RE: Check constraints was: Imbedded SQL vs Sequence object

From: rob@xxxxxxxxx

How would one check against the WRONG customer in a batch feed (like from
EDI) that couldn't be done with a trigger? Even interactively, in a
server program, you have to remain interface neutral (so a standard pop up
of "are you really sure?" doesn't fit the bill). After all, the same
server program could be used from 5250, VARPG, browser, etc.

The simplest case would be authorization. If you had business logic that
identified which customers a user profile was authorized to, that
information could be checked by the server quite easily. Not so in
constraints.

I am trying to fathom how, and even if I use "Gee, we only allow customer
12345 to be used if they are ordering 'XYZ' via EDI on PO '456'" I still
think that would be as easy to handle in a trigger as on a server program.

Triggers are different than constraints. I wasn't asking about triggers. I
was asking about constraints. Check the subject line.

And while triggers are better then constraints, they are still one record at
a time, and this they are still unable to catch circular references or
multi-table business rules in multiple-record adds. A server program has
the additional benefit of being able to take in an entire order and process
it atomically.

So, you can have constraints which can't even catch basic business rules,
and triggers which can't handle sophisticated multi-table and multi-record
issues, and then finally business rules in a server to do the hard stuff.
Or you can code it all in the serer in the first place.

Me, I prefer the latter.

If I really stretch the imagination I suppose the interface to the server
program would be some huge undelimited data structure that allows for more
and more fields to be used in the undefined space to supply more data to
the server program as time goes by. Like customer number, item ordered,
call stack, PO. Granted, call stack can be determined, but may be all
those fields are not easily accessible from a trigger.

You pass a data structure to the server. The data structure typically
closely matches the database (although for a number of reasons, it doesn't
have to!). The interface can be anything that can populate the data
structure. For a web service, it would be XML. In RPG, just populate the
DS the same way you would a record.

The only time it's even mildly complicated is when you pass an entire array
of records to be edited at one time. But since that's something you can't
do at all with a trigger, it's really a positive that it can be done at all.

Then again the
documentation about the use of the datastructure can get quite ugly quite
fast. The developer calling that server program then starts wondering
what parameters are required or conditional or reserved for future use,
and if I got to put that kind of thought into it, why can't I just update
the data already - heck fire, I've already gone through that much editing?

The information passed to the server is exactly the same information that is
passed to the database.

And part of me still thinks that if the developer can gather that
information then surely the trigger can also.

Again, the original question was about constraints, not triggers. You're
concentrating on the trigger straw man to avoid my original point about
constraints.

If you want to talk about triggers, fine, change the subject.

Joe