In a well-structured database application, SQL statements are typically not distributed over the entire application but concentrated in a single access layer instead. This access layer has a procedural interface to the rest of the application at which the operations for application objects are made available in form of abstract data types.
In client/server configurations, the client and server interact when an SQL statement is executed in the access layer. The number of these interactions can be reduced considerably by transferring the SQL access layer from the client to the server.
SAP DB provides a language (special SQL syntax) for this purpose that allows an SQL access layer to be formulated on the server side. This special SQL syntax can be used to define database procedures and
triggers.This has three main advantages:
To be able to execute a database procedure, users must have the call privilege. This call privilege is independent of the user privileges for the tables and columns used in the database procedure. As a result, users may be able to use a database procedure to execute SQL statements that they otherwise would not have access to.
Database procedures are called explicitly from the programming language of the application. They can contain parameters, except for
LONG columns. The extent to which LONG columns can be used within database procedures depends on the length of the LONG columns and the amount of storage space available.As with any SQL statement, precautions must be taken to ensure that calling a database procedure has the desired effect, and that errors do not have any lasting effects on the database system. SAP DB provides nested transactions for this purpose. Each database procedure call can run in a
subtransaction that can be reset without interfering with transaction control in the database application.
See also:
Name of a database procedure