|
Stored procedures are specialized programs that are executed under the control of the DBMS. You can think of stored procedures as similar to other database objects such as tables, views and indexes because they are managed and controlled by the RDBMS. But you can think of stored procedures as similar to application programs, too because they are coded using a procedural programming language.
However, a stored procedure is not "physically" associated with any other object in the database. It can access and/or modify data in one or more tables. Basically, you can think of stored procedures as "programs" that "live" in the DBMS.
A stored procedure must be directly and explicitly invoked before it can be executed. In other words, stored procedures are not event driven. Contrast this concept with the concept of triggers, which are event-driven and never explicitly called. Instead, triggers are automatically executed (sometimes referred to as "fired") by the DBMS as the result of an action. Stored procedures are never automatically invoked.
This subject is too complex to cover in adequate detail in this forum. I suggest you download and read the following manuals for in-depth coverage of how DB2 implements stored procedures:
SG24-4693: Getting Started with DB2 Stored Procedures: Give Them a Call through the Network
SG24-5945: DB2 Java Stored Procedures: Learning By Example
SG24-5485: Cross-Platform DB2 Stored Procedures: Building and Debugging
SG24-7083: DB2 for z/OS Stored Procedures: Through the CALL and Beyond
All of these manuals can be downloaded free-of-charge.
Editor's note: Do you agree with this expert's response? If you have more to share, post it in one of our discussion forums.
|
