RE: Anyone using the *AFTER *READ Triggers in V5R1/V5R2?

This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
All the more reason for UDF's.  UDF's can follow your business rules by
calling your HLL programs to return the proper values.

Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin




"Joe Pluta" <joepluta@PlutaBrothers.com>
Sent by: midrange-l-admin@midrange.com
11/25/2002 10:54 PM
Please respond to midrange-l

        To:     <midrange-l@midrange.com>
        cc:
        Fax to:
        Subject:        RE: Anyone using the *AFTER *READ Triggers in
V5R1/V5R2?


> From: jpcarr@tredegar.com
>
> CREATE VIEW clearview
> As Select
> Ordno,
> CASE  Status
> When 'O'  Then 'Open'
> When 'C'  Then 'Closed'
> End
> AS Status

I'll put my piece in once, then get out of it.

Unless you're prepared to go whole-hog and redeploy all of your business
rules in SQL, I would caution against doing something like this.  Why?
Well, because it isn't very flexible.  This particular example fares very
poorly in a multi-lingual environment.  You'd want to get the values from
a
message file or some other reference object, and HLL programs are better
at
that than SQL.  As to advanced arithmetic operations, except for the more
trivial issues like sum and average, such operations are more than likely
going to require parameters from other files.  And once the rules get too
complex for a simple SQL statement, now you have to go back and reengineer
your code.

The more I see this sort of issue arise, the more I'm convinced that a new
layer needs to be added to the traditional model.  This layer separates
the
traditional database tier into a business attribute tier and a data
deployment tier.

But as I said, I just wanted to comment on this particular example.  It
would not work well for many packages, though it might be fine for a
company
that never intends to do any international business.

Joe

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.