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.

All stored procedures running on the server share the same virtual user session. This session is returned as an object of the Session class by the Session command. 

Session objects allow you to get information about the session and to share data between processes, thanks to the .storage property.

The virtual user session is available from the following contexts:

• methods called with the Execute on server command,
• On Server Startup, On Server Shutdown, On Backup Startup, On Backup Shutdown, and On System event database methods

Note: Every user session on the server has its own Session object. For more information, see this page on developer.4d.com.

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:

• On Server Startup Database Method
• On Server Shutdown Database Method
• On Server Open Connection Database Method
• On Server Close Connection Database Method

Five other database methods can be executed either on the server machine or a client machine depending on the context:

• On Web Authentication Database Method
• On Web Connection database method
• On SQL Authentication Database Method
• On Backup Startup Database Method
• On Backup Shutdown Database Method

Three database methods can only be executed on a client machine:

• On Startup database method
• On Exit database method
• On Drop Database Method

For more information on the database methods see the corresponding sections in this manual and in the 4D Language Reference manual

• 4D Server maintains one table of interprocess variables. The scope of these variables is the server machine. When running a compiled database, the interprocess variable table definition is common between the server and all the clients machines, each machine having its own instance.
• Like all processes, each stored procedure, database method and trigger has its own table of process variables. These process variables can be created and used dynamically during each phase of execution.

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.