In Mimer SQL you can define functions, procedures and modules, collectively known as stored procedures.
Mimer SQL stored procedures enable you to define and use powerful functionality through the creation and execution of routines. By using stored procedures, you can move application logic from the client to the server, thereby reducing network traffic. This will also allow the logic to be shared between different applications.
Stored procedures are stored in the data dictionary and you can invoke them when needed.
For a complete and detailed discussion of stored procedures, see Mimer SQL Reference Manual, Functions and the Mimer SQL Programmer's Manual, Mimer SQL Stored Procedures.
Stored procedures execute their statements using the user context of the creator of the stored procedure, independent of the actual current user.
Routines - Functions and Procedures
The term routine is a collective term for functions and procedures. Functions are distinguished from procedures in that they return a single value and the parameters of a function are used for input only. A function is invoked by using it where a value expression would normally be used.
Mimer SQL supports standard procedures and also result set procedures, which are procedures capable of returning the row value(s) of a result-set.
Standard procedures are invoked directly by using the CALL statement and can pass values back to the calling environment through the procedure parameters.
A result set procedure is invoked by using the CALL statement, and the result-set values are presented in the same way as for a SELECT statement.
In Embedded SQL, ODBC and JDBC, result set procedures are invoked by declaring a cursor which includes the procedure call specification and by then using the FETCH statement to execute the procedure and return the row(s) of the result-set.
The creator of a routine must hold the appropriate access rights on any database objects referenced from within the routine. These access rights must be held for the life of the routine.
Routine names, like those of other private objects in the database, are qualified with the name of the schema to which they belong.
A module is simply a collection of routines. All the routines in a module are created when the module is created and belong to the same schema.
If a module is dropped, all the routines contained in the module are dropped.
Under certain circumstances a routine may be dropped because of the cascade effect of dropping some other database object. If such a routine is contained in a module, it is implicitly removed from the module and dropped. The other routines contained in the module remain unaffected.
In general, care should be taken when using DROP or REVOKE in connection with routines, modules or objects referenced from within routines because the cascade effects can often affect many other objects. See Dropping Objects from the Database and Recursive Effects of Revoking Privileges for details.
A trigger defines a number of procedural SQL statements that are executed whenever a specified data manipulation statement is executed on the table or view on which the trigger has been created.
The trigger can be set up to execute AFTER, BEFORE or INSTEAD OF the data manipulation statement. Trigger execution can also be made conditional on a search condition specified as part of the trigger.
Triggers are described in detail in the Mimer SQL Programmer's Manual, Triggers.
Mimer Information Technology AB
Voice: +46 18 780 92 00
Fax: +46 18 780 92 40