Re: Trigger programme without a trigger.

If the concept of the-program controls all I/O to the file is acceptable as an assumption, then the-program is best to *also* serve as the arbiter for any [triggered] action to perform in response to any I/O requests. Since the trigger concept is nothing more than provision for additional logic being applied to an I/O event, then the-program simply needs to add the necessary logic for whichever I/O events require the additional action, such that the-program is the trigger [for additional logic].

Since there is only a limited ability to ensure that the given assumption [that all I/O is via only one program] can be met, the future is not generally bleak for use of trigger programs. That is because a trigger enables placing\deferring business logic in\to the database rather than merely hoping\assuming that all possible I/O will be via the-program. When any application is able to open and perform I/O on the file without having applied the [same\expected] business rules, the failed assumption that the-program would have been the arbiter of all I/O activity, could be very problematic.

Rather than the Database Open Exit, a nice feature to request might be an Open-Database file trigger. An /open trigger/ could limit the scope of an open exit program, to only those files for which an explicit request had added an /open trigger/. Either could be used as preventive for any application other than the-program, from opening the file.

Regards, Chuck

David FOXWELL wrote:

Ok. Got a response as to why no trigger.

Recently I asked for advice while creating a unique module for a new
PF, which I took and I now have a module that does all the business
logic and input/output on that new file.

So now the reasoning is, since all input to the file has to pass by
this module, the use of a trigger is superfluous. We just call the
procedure at each modification of the file. The future looks bleak
for trigger programs.

Anyone still find a hole to pick with the idea?...