Server-side Error Handling

A transaction is a group of SQL statements whose effects are logically connected. Anything from simple queries to inserting, and deleting operations can be considered a transaction, as well as more complex groups of several statements which accomplish a specific task.

A recordset is the result of executing an SQL query. It is composed of multiple rows, each row having multiple columns. The columns presented in the query result depend on the column list declared in the query (they can belong to different tables). The number of rows and their order depend on the query conditions (WHERE, GROUP BY, HAVING, ORDER). The recordset acts as a source of dynamic data in web applications.

A query is a SQL command that will extract information from the tables of a database. Essentially, a query is a request for information from your database.

The InterAKT Dynamic Data tool is a replacement for the standard dynamic data dialog. It is used in the MX Kollection 3, to provide a unified way of building mark-ups, or place holders. These are recordset fields, server or session variables, and other types of dynamic data that are replaced at runtime by their corresponding values

An AFTER trigger is a specific type of trigger which is executed after a database transaction. Common uses of AFTER triggers are to propagate values to fields other than those involved directly in the transaction, or to accomplish tasks such as sending a confirmation e-mail message.

A database refers to data organized and stored on a computer that can be searched and retrieved by a computer program. Most industrial-strength and many smaller database applications can be addressed using SQL (Structured Query Language).

Server-side Error Handling

This section offers information about the transaction recordset's role in handling the occurring errors. This includes the way the Transaction Engine deals with the errors that occur, and the development and production debug modes, and switching between them.

At development time, the developer is interested to see exactly in which part of the transaction the error occurred and a more detailed error message (e.g. for a failed file upload, what caused the failure (missing write permissions on the upload folder, etc) and where in the transaction the error occurred (the AFTER trigger that performed the upload failed)).

Once the application is deployed and becomes a "live" application, the developer will want to hide these complex error messages to the user and display a message like: "An error occurred while uploading the file. Please contact the system administrator." or something similar.

This is why any error will have to have a "development-time" error message and a "deployed-time" error message. Depending on the configuration, the Transaction Engine 3 will display the appropriate error message.