Triggers

Home

4D v16

Triggers

In addition to the manipulations explained in the video, you should also note that:

By calling an ENGINE event, there’s an important precision to note: triggers are executed on the triggers database engine:

In single-user, it’s the 4D program that contains both the database event and the return event (displays, etc.).
In client/server mode (SQL server or Web server), data is stored on the server and sent to client machines using the 4D Server engine. In this case, triggers are executed on the server and not locally on the client machines.

Generally speaking, get used to creating project methods that take care of your processes, calculations, etc. and call these “generic” methods from specific methods such as triggers.

We saw how to pass parameters, so make good use of it! It’s a lot easier to maintain and you save a considerable amount of time developing as well as bug fixing. Your code will be a lot more concise, reliable, and readable.

You can execute cascading triggers. In this case, 4D has commands that allow finding out the trigger properties and its cascade level.

A trigger can also serve to "accept" or "reject" any operation attempt on the record.

This is a way to allow you to ensure the integrity of your database regardless of how information is processed:

SQL
plug-in
input
import
Web

Knowing that a trigger blocks the other processes during execution, the main rules to follow in a trigger are:

speed of execution
no interface (alerts, messages, etc.)

Video script

In this video, we're going to learn how to configure database events and how to take them into account in the programming.
A trigger (or table method) is used to check on actions performed by the database engine on data:

creation
modification
deletion.

In that sense, a trigger is a method like any other. It's simply the context in which it is executed that changes.

Like form events, database events must be checked so that 4D gives control to the trigger to execute.

We can enable any database event in the Table inspector.

You’ll find the “Edit” button at the bottom right, which allows creating the method to execute when the checked events occur.

The method is generally structured in the following manner:

 $evt:=Database event `What is the number of the event being executed by the database event?

 Case of

    :($evt=On Saving New Record Event) `A new record is saved

 

    :($evt=On Saving Existing Record Event) `An existing record is saved

 

    :($evt=On Deleting Record Event) `A record is deleted

 

 End case

Unlike a form method that is only executed during a display (or print), a trigger is executed regardless of how you access records:

programming
import/export
SQL
Web
and so on.

The trigger has the advantage of being a mandatory passage point.

Let's add a Date_Last_Modified field to the Interventions table
We'll make it visible on the form
And assign a value to it whenever we save a record:

[Interventions]Date_Last_Modified:=Current date

Of course, this latest modification will also be valid when creating a record.

Let's try it out by performing a modification:

If we change the intervention date
Then save it and come back here, the modification date has in fact been assigned a value
So the trigger works correctly.