


1. In a well structured ADABAS application, the SQL statements are typically not distributed over the entire application but are concentrated in a single access layer. This access layer has a procedural interface with the rest of the application at which the operations for application objects are made available in form of abstract data types.
2. In client server configurations, there is an interaction between client and server when executing any SQL statement in the access layer.
3. The number of these interactions can be drastically reduced when the SQL access layer is no longer run on the client but on the server.
ADABAS provides a language for this purpose which allows an SQL access layer to be formulated on the server side.
4. This has three main advantages:
- The number of interactions between client and server is reduced by several factors. Client-server communication is only required for each operation on the application object, not for each SQL statement. This enhances the performance of client-server configurations considerably.
- The second advantage has to do with software engineering. The SQL access layer contains the procedurally formulated integrity and business rules. Their concentration on the server side and their elimination from the ADABAS applications have the effect that modifications to these rules can be made at a central place, immediately becoming valid for all ADABAS applications. In this way, the integrity and decision rules become a part of the database catalog.
- An SQL access layer in the form of DB procedures transferred to the server side is an essential customizing tool, because it allows customer-specific database functionality to be provided.
5. To be able to perform a DB procedure, a user must have the call privilege for it. This call privilege is independent of the privileges granted to the user for the tables and columns used within the DB procedure. Therefore, a user may be able to execute SQL statements using a DB procedure, but cannot do so outside the DB procedure.
6. DB procedures are called explicitly from the programming language of the application. DB procedures can contain parameters, except for LONG columns. In a DB procedure, all SQL statements (DDL and DML) are available without any restrictions. The extent to which LONG columns can be used within DB procedures depends on the length of the LONG columns and the storage space available.
The call of further DB procedures is supported.
7. For the call of a DB procedure, as for any SQL statement, it must be ensured that there are the desired effects in case of success and that there remain no effects in the database if errors occur. ADABAS provides nested transactions for this purpose. Each call of a DB procedure can be executed within a subtransaction which can be reset without interfering with the transaction control of the ADABAS application.
8. For the syntax and semantics of DB procedures, refer to the manual of the corresponding ADABAS component.


