With 4D Server, you have several situations in which you can execute 4D code on the server machine:
- Triggers
- Stored procedures
- Project methods with the "Execute on Server" attribute
- Database methods
A Trigger is a method attached to a table. Triggers can prevent “illegal” operations on your database records. They are a very powerful tool to restrict operations on a table, as well as to prevent accidental data loss or tampering. For example, in an invoicing system, you can prevent anyone from adding an invoice without specifying the customer to whom the invoice is billed.
Triggers are executed on the machine where the database engine is actually located.
With 4D Server, triggers are executed within the context of processes running on the server machine, and not on the client machine. More specifically, they are executed in the context of the "twinned" processes of the user processes that call the database operation. These twinned processes share the database context with the user process on the client machine (in particular, the state of transactions and the locking of records) but do not share the language context (variables, processes, sets, current selections). Note however that the current record of the table of the trigger is the same in all contexts.
For more information about triggers, see the section Triggers of the 4D Language Reference manual.
Note: On the server, a trigger is executed in the process responsible for the associated action (create/update/delete). If the action was triggered from a preemptive process on the server (e.g. a stored procedure, a http request in scalable session mode), then the trigger will be executed in the same preemptive process. But, if the action was triggered from a 4D remote, then the trigger will be executed in the twinned process, which is always in cooperative mode (a twinned process is shared for all calls of a user). See Preemptive processes on developer.4d.com.
A 4D stored procedure is project method executing a process method in a process running on the server machine (or on any client machine), instead of on the client machine which has launched the method. See the Stored Procedures section.
Project methods that have the "Execute on Server" attribute are also executed on the server. However, unlike stored procedures, they are executed in the "twinned" process of the client process and thus benefit from its database context, like with triggers. For more information, please refer to the Execute on Server attribute section.
Four database methods are executed only on the server machine:
Five other database methods can be executed either on the server machine or a client machine depending on the context:
Three database methods can only be executed on a client machine:
For more information on the database methods see the corresponding sections in this manual and in the 4D Language Reference manual
With 4D Server, the visibility of sets and named selections depends on where they were created (server process or client process) and the type of these objects (local, process or interprocess objects). For more information, see the 4D Server, Sets and Named Selections4D Server, Sets and Named Selections section.