Re: Externalizing I/O was RPG read loops

[Raul Jager <raul@xxxxxxxxxx>]

Trigger do work well with Web aplications, as a matter of fact, I find 
it hard to use the access routines from Net.Data, but the trigger is 
always there, regardless of the user interface.

I think an *AFTER trigger will have no problem with recursion.
_______________________________________________________________________
Fisher, Don wrote:

> Both.  We're a small shop with only six developers.  I admit to being the
> one pushing this architecture, though.
>
> As I understand it, another benefit is these access programs could
> eventually be tweaked to support browser based applications and "green
> screen" applications simultaneously.  Tough to do that with triggers. 
>
> Another problem with triggers is recursion.  If I need to update a related
> record in the same file, I'd need to have my trigger program in a *NEW
> activation group, which creates a lot of overhead.  Using access procedures
> in service programs eliminates that problem.
>
> As for stopping errant developers, a trigger could be used for that, though
> we don't here. 
>
> Just my current opinion, which, of course, may change later. 
>
> Donald R. Fisher, III
> Project Manager
> Roomstore Furniture Company
> (804) 784-7600 extension 2124
> DFisher@xxxxxxxxxxxxx
>
> <clip>
> I get my enforcement of business rules with triggers and constraints. 
> Stops even the errant developer who updates a file directly with any
> utilities.  Again, only one place to maintain the logic.  Don, are you the
> developer of these functions, or only a user?
> <clip>
>