DB2 9.5 SQL Procedure Developer Exam 735 Prep, Part 2

DB2 9.
5 SQL Procedure Developer exam 735 prep, Part 2: DB2 SQL procedures
Skill Level: Intermediate Marina Greenstein (greenstm@us.ibm.com) Executive IT Specialist IBM Shakeb Shere (shakebs@ca.ibm.com) IBM DB2 Common Client Technologies advanced support analyst IBM
02 Oct 2008 This tutorial introduces the SQL procedure as it relates to DB2 V9.5. Learn about DB2 9.5 SQL procedures, including an introduction to stored procedures, the advantages of using stored procedures, and the differences between SQL procedures and external procedures. Learn about different SQL procedure statements and see how to invoke and share nested stored procedures. Test and deploy stored procedures and discover how to secure SQL procedures. This tutorial is the second in a series of six tutorials designed to help you prepare for the DB2 9.5 SQL Procedure Developer Certification Exam (735).
Section 1. Before you start

About this series
Thinking about seeking certification on DB2 SQL Procedure Developer (Exam 735)? If so, you've landed in the right spot. This series of six DB2 certification preparation tutorials covers all the basics -- the topics you'll need to understand before you read the first exam question. Even if you are not planning to seek certification right away, this set of tutorials is a great place to start learning all about database development for DB2 V9.5.
DB2 SQL procedures Copyright IBM Corporation 2008. All rights reserved.
Trademarks Page 1 of 24
developerWorks
ibm.com/developerWorks
About this tutorial

In this tutorial, you'll learn about DB2 9.5 SQL procedures, including an introduction to stored procedures, the advantages of using stored procedures, and the differences between SQL procedures and external procedures. Learn about different SQL procedure statements and see how to invoke and share nested stored procedures. Test and deploy stored procedures and discover how to secure SQL procedures. This is the second in a series of six tutorials you can use to help prepare for the DB2 9.5 SQL Procedure Developer exam 735. The material in this tutorial primarily covers the objectives in Section 2 of the test, which is entitled "SQL Procedures." See Resources.
Prerequisites
This tutorial is written for Linux, UNIX, or Windows database developers or administrators, whose skills and experience are at a beginning to intermediate level. You should have a general familiarity with using a UNIX or Windows command-line shell and a working knowledge of DB2 and SQL commands.
System requirements
The examples in this tutorial are specific to DB2 9.5 running on a Windows operating system. The concepts and information provided are relevant to DB2 running on any distributed platform. You do not need a copy of DB2 9.5 to complete this tutorial. However, you will get more out of the tutorial if you download the free trial version of IBM DB2 9.5 to work along with this tutorial.
Section 2. Stored Procedures

What is a stored procedure?
A stored procedure (also referred to as a routine) is a database object that contains a series of SQL statements and application control logic that can formulate business
developerWorks
logic and are executed directly on the database server. The business logic gets encapsulated inside the stored procedure, and it can then be invoked from client applications, other stored procedures, user-defined functions or from triggers via an SQL statement. Stored procedures can accept parameter values to change the behaviour of the business logic based on the input data. They can then return output values back to the caller or they can return multiple result sets to the caller. Stored procedures can be implemented using the SQL Procedure Language (SQL PL) or a programming language such as Java or C. Stored procedures can considerably improve the performance of a distributed application (an application running on a remote system) by: Reducing the amount of network traffic Reducing the coding efforts involved with application developers Providing a non-complex way of invoking a remote stored procedure from a distributed client Figure 1 shows a situation in which stored procedures are useful: Figure 1. Reducing network traffic by using stored procedures
Advantages of using stored procedures

The following benefits can be gained from using stored procedures:
developerWorks
Simplifies code reuse, code standardization and code maintenance: A series of different applications that may all need to perform a similar task can be done quite easily by coding a single stored procedure to perform that task, and having each client application invoke that stored procedure so that task can be executed. If the task needs to be modified, then only the affected stored procedure would need to be modified, otherwise each application would need to be changed. Controlled access to other database objects: A user who does not possess the access privilege to a particular database object or operation on a database (e.g., creating a table), but who wishes to perform action on that object or an operation, may accomplish his goal by invoking a stored procedure that he has the authority to run. This means that privilege management can be simplified. Improving application performance: For remote applications, each SQL statement that is issued needs to be transmitted through the network separately one at a time. This can result in high levels of network traffic. By adding all of these statements inside a single stored procedure, only one network request gets made by the client application to invoke that stored procedure. This, of course, minimizes the amount of network traffic involved, and thus improves the overall performance of the application. More efficient SQL: Since stored procedures reside at the database server and are essentially database objects themselves, they have the ability to perform better than client applications because SQL requests are transmitted much more efficiently. Stored procedures using embedded SQL operations also have their access plans already stored in packages, thus improving the time it takes to execute each statement. If the stored procedure is created with the NOT FENCED clause, then the stored procedure runs in the same process space as the database manager which allows communication to be done within shared memory. Enhanced capabilities: Since a stored procedure resides on the database server, it tends to have more access to memory and disk space then the application
developerWorks
would. Applications have access to software that is installed on the database server. Interoperability: Different code modules may be implemented in different programming languages by different programmers. To help achieve code reuse with the interoperability of logic, stored procedures themselves can be written in different languages. A client application coded in a different language can invoke a stored procedure written in a different language (for example, a stored procedure written in Java can be invoked from an application written in C++). Also stored procedures written in different languages can invoke each other (for example, a stored procedure written in C can invoke a stored procedure written in Java). The operating system of the client and the operating system of the server where the stored procedure is located can also be different (for example, a Windows client application can invoke a stored procedure running on AIX).
Limitations of stored procedures

There is an interoperability with invoking stored procedures, such that the client application can be of a different programming language from the stored procedure. However, external stored procedures written in a specific language would only work on certain platforms. For example, a CLR stored procedure can only function on a Windows-based platform. This stored procedure can be invoked from anywhere; however, if the server is to be migrated to a different platform (for example, Solaris or AIX), then the stored procedure needs to be re-written. This would also be true for stored procedures written in C, C++ or COBOL, where the stored procedure would need to be re-compiled on the new server. SQL procedures would not have this problem. Java stored procedures are also more flexible, but the new database server would need to have a Java Virtual Machine (JVM) installed in order to execute the stored procedure. The only SQL statement that can invoke a stored procedure is the CALL statement. The CALL statement can be used from applications, stored procedures, user-defined functions or triggers. Stored procedures are allowed to be nested such that one stored procedure can call another stored procedure, which can then call another stored procedure. DB2 v9.5 has a maximum limitation of 64 stored procedures that can be nested at one time.
developerWorks
Stored procedures cannot preserve state between invocations. A stored procedure output parameter cannot directly be used with another SQL statement. The calling interface needs to assign the output parameter to some variable, and then can use that variable with another SQL statement later on if it chooses to. Scrollable cursors are not supported with stored procedures.
Differences between external stored procedures and SQL stored procedures

There are two types of stored procedures that DB2 supports. External stored procedures and SQL procedures. External stored procedures have their logic defined in a programming language application that exists outside of the database. The executable or library for this type of stored procedure exists in the file system in which the database server is installed. The external stored procedure, like the SQL procedure, is registered with the database, but during the registration process, the location of the stored procedure executable or library needs to be specified. DB2 supports external stored procedures in a variety of programming languages including C, C++, COBOL, Java and .NET (also referred to as a CLR stored procedure). The following features are unique to external stored procedures: External stored procedures allows access to non-database interfaces such as the file system, or applications. They can use these resources even if they are not part of the database system specifically. As an example, an external stored procedure can execute a shell script on a UNIX database server to run a specific task. External stored procedures use parameter styles to determine how a certain input, output, or input/output parameter is to be used by the programming language used for that stored procedure. Some parameter styles allow the use of passing meta-data information such as database and stored procedure property information in a structure known as dbinfo that might be useful to the stored procedure. External stored procedures can be defined as FENCED or NOT FENCED. This determines if the stored procedure should run in the same address space as the database manager (NOT FENCED), or if it should run in its own process (FENCED). A stored procedure defined as NOT
DB2 SQL procedures Copyright IBM Corporation 2008. All rights reserved. Trademarks Page 6 of 24
developerWorks
FENCED performs slightly faster since it does not need to communicate using shared memory segments; however, they can be riskier. An unfenced stored procedure can cause the database server to crash if there is a problem with the stored procedure since it will be using the same address space as DB2. Java stored procedures must be defined as FENCED; however, they can be defined as THREADSAFE or NOT THREADSAFE. The following features are unique to SQL procedures: SQL procedures are only written in SQL using a language called SQL Programming Language (SQL PL). More information about this language can be found in the previous tutorial of this series (see Resources). So, the main difference between external stored procedures and SQL procedures is that external procedures are coded using a specific programming language, whereas SQL procedures are coded using only SQL statements. SQL procedures reside in the actual database. Unlike external stored procedures which have a dependency on an external library or executable that exists in the file system, an SQL procedure is part of the database. Building an SQL procedure does not require a compiler or a deep understanding of a specific programming language. So the development of an SQL procedure might be quicker. SQL procedures are always defined as NOT FENCED. There is less risk involved with these types of stored procedures since only SQL operations can be performed by the stored procedure limiting the risk involved with the database server. SQL procedures are more portable. Since they do not rely on a specific programming language whose compiler or interpreter would be needed on each database server, it would be easier to re-create these stored procedures on each server that needs them.
Section 3. SQL procedure structure

The SQL procedure structure consists of the CREATE PROCEDURE statement, parameters, and compound statement. The following pseudo-diagram shows the
developerWorks
structure of an SQL procedure: Listing 1. Structure of an SQL procedure

CREATE PROCEDURE proc_name IN, OUT, INOUT parameters optional clauses SQL procedure body - compound statement
The CREATE PROCEDURE statement defines the characteristics and logic of the stored procedure which is stored in the DB2 system catalogs (for example, SYSCAT.PROCEDURES). Listing 2. CREATE PROCEDURE command syntax
CREATE PROCEDURE--procedure-name-----------------------------> >--+----------------------------------------------------+--?----> '-(--+------------------------------------------+--)-' | .-,------------------------------------. | | V .-IN----. | | '---+-------+--parameter-name--data-type-+-' +-OUT---+ '-INOUT-' >--+-------------------------+--?-------------------------------> '-SPECIFIC--specific-name-' .-DYNAMIC RESULT SETS 0--------. .-MODIFIES SQL DATA-. >--+------------------------------+--?--+-------------------+---> '-DYNAMIC RESULT SETS--integer-' +-CONTAINS SQL------+ '-READS SQL DATA----' .-NOT DETERMINISTIC-. .-CALLED ON NULL INPUT-. >--?--+-------------------+--?--+----------------------+--?-----> '-DETERMINISTIC-----' .-INHERIT SPECIAL REGISTERS-. .-OLD SAVEPOINT LEVEL-. >--+---------------------------+--?--+---------------------+----> '-NEW SAVEPOINT LEVEL-' .-LANGUAGE SQL-. .-EXTERNAL ACTION----. >--?--+--------------+--?--+--------------------+--?------------> '-NO EXTERNAL ACTION-' >--+------------------------------+--?--------------------------> '-PARAMETER CCSID--+-ASCII---+-' '-UNICODE-' >--| SQL-procedure-body |--------------------------------------><
The most commonly used components of this diagram are the procedure_name and the parameters (IN/OUT/INOUT). The procedure_name is an SQL identifier that can be qualified with a SCHEMA NAME whose maximum limit is 128 characters.
developerWorks
The parameters (IN/OUT/INOUT) are used to provide a mechanism for specific data to be sent into the stored procedure, or for data to be returned from the stored procedure. Each stored procedure defined in the system catalogs is distinguished by name and the number of parameters (regardless of their datatatypes). No two identically-named procedures within a schema are permitted to have exactly the same number of parameters. IN is the default and is not required to be specified. For example, "CREATE PROCEDURE test1 (p1 INT, OUT p2 INT)" defines a stored procedure with one input and one output parameter. Please note that a stored procedure can be created without paramertes as well, for example, "CREATE PROCEDURE test2." SPECIFIC--specific-name assigns the stored procedure a specific name, rather than having DB2 assign a system-generated unique name for it. This is useful if you use overloaded stored procedures with the same name and different number of parameters. This specific name can be used when dropping the stored procedure. It can never be used to invoke the stored procedure. The qualified form is a schema name followed by a period and an SQL identifier (the limit is 18 characters). If the specific name is not specified, a unique name is generated by the database manager. The unique name is 'SQL' followed by a character timestamp: 'SQLyymmddhhmmssxxx'. CONTAINS SQL, READS SQL DATA, MODIFIES SQL DATA indicates the level of data access from stored procedure. If any data manipulation is performed within the stored procedure, for example the use of GLOBAL TEMPORARY TABLES, then the stored procedure need to be specified with the MODIFIES SQL DATA option. If the BEGIN ATOMIC clause is used in a compound SQL procedure, the stored procedure can only be created if it is defined with MODIFIES SQL DATA. SQL procedure body is the main body of the stored procedure. At its core is a compound statement. Compound statements are bounded by the keywords BEGIN and END. These statements can be ATOMIC or NOT ATOMIC. By default they are NOT ATOMIC. SQL Procedures requires particular order of declarations and executable statements within compound statement. Figure 2 illustrates the structured format of a compound statement within SQL procedures: Figure 2. Structured format of a compound statement
developerWorks
ATOMIC and NOT ATOMIC compound SQL

There are two types of compound statements: NOT ATOMIC (default) and ATOMIC. NOT ATOMIC If an unhandled error condition occurs, no SQL statements are rolled back. Listing 3 demonstrates how it works. Listing 3. NOT ATOMIC compound statement
CREATE TABLE t1 (c1 INT, c2 CHAR(5))! CREATE PROCEDURE my_proc1 () SPECIFIC not_atomic_example P1: BEGIN NOT ATOMIC INSERT INTO t1 VALUES(1, 'FIRST'); --(1) -- SIGNAL SQLSTATE TO INFORCE ERROR SIGNAL SQLSTATE '70001' SET MESSAGE_TEXT = 'INFORCE ERROR'; INSERT INTO t1 VALUES (2,'SECND'); --(2) END P1!
If INSERT (1) is executed successfully, then an error is enforced and the SQL procedure is terminated without ever executing INSERT (2). Since this SQL procedure was created with the NOT ATOMIC statement, the first INSERT statement is not rolled back. If you query table T1 after the stored procedure execution, it will return:
C1 C2
developerWorks
FIRST
ATOMIC During execution of an ATOMIC compound statement, if any unhandled error conditions arise within it, then all statements that have been executed up to that point are rolled back. ATOMIC statement cannot be nested inside other ATOMIC compound statements. Listing 4 shows procedure with an ATOMIC compound statement: Listing 4. Procedure with ATOMIC compound statement
CREATE PROCEDURE my_proc2 () SPECIFIC atomic_example P1: BEGIN ATOMIC INSERT INTO t1 VALUES(3, 'THIRD'); --(1) -- SIGNAL SQLSTATE TO INFORCE ERROR SIGNAL SQLSTATE '70001' SET MESSAGE_TEXT = 'INFORCE ERROR'; INSERT INTO t1 VALUES (4,'FOUR'); --(2) END P1
If INSERT (1) is executed successfully, then an error is enforced and the SQL procedure is terminated without ever executing INSERT (2). Since this stored procedure was created with the ATOMIC statement, the first INSERT is rolled back. If you query table T1 after the SQL procedure executes, it still returns the only one row that had been inserted by the previous example:
C1 C2 1 FIRST
Compound SQL and scope of variables

You can have one or more compound statements within SQL procedures. Those compound statements could be nested or one can follow another. Each compound statement introduces a new scope for a local variable where those variables can be used. That is why we recommend using labels when you have more than one compound statement within a store procedure. Look at Listing 5 as an example: Listing 5. Nested Compound blocks
CREATE PROCEDURE VAR_SCOPE ( L1:BEGIN DECLARE v_outer1 INT; )
developerWorks
DECLARE v_outer2 INT; L2:BEGIN DECLARE v_inner1 INT; DECLARE v_inner2 INT; SET v_outer1 = 100; --(1) -- success SET v_inner1 = 200; END L2; SET v_outer2 = 300; SET v_inner2 = 400; --(2) -- fail END L1
Attempting to build this SQL procedure gives you the following error message: DB2ADMIN.VAR_SCOPE: 12: "V_INNER2" is not valid in the context where it is used.. SQLCODE=-206, SQLSTATE=42703, DRIVER=3.50.152 Note that statement (1) passes successfully as v_outer1 and is declared outside of the compound statement, but statement (2) fails because v_inner2 is not declared outside of the compound statement.
Section 4. Nested stored procedures

Invoking nested procedures
DB2 supports the CALL statement to invoke one procedure from another (referred to as a nesting store procedures). The following diagram illustrates the CALL statement syntax: Listing 6. CALL statement syntax
>>-CALL--procedure-name--+--------------------------+---------->< | .-,--------------. | | V | | '-(----+-expression-+-+--)-' '-NULL-------'
Note that DB2 is strongly typed and parameters types in the CALL statement need to be compatible with parameters in the CREATE PROCEDURE statement of the calling stored procedure. The nth argument of the CALL statement corresponds to the nth parameter defined in the CREATE PROCEDURE statement for the procedure. Listing 7 demonstrates this relation: Listing 7. Correlation of CALL statement to CREATE PROCEDURE statement
developerWorks
CREATE PROCEDURE NESTA (p1 int, p2 char(10), OUT p3 INT) BEGIN SQL Statements END
Now, call this procedure from another one: Listing 8. Calling procedure
DECLARE v_v1 varchar(10); DECLARE v_res INT default 0; --- SQL statements and variable assignments CALL nesta(10, v_v1, v_res);
In summary, here are the rules for passing parameters to stored procedure: Variables and parameters are strongly typed (they must match) Local variables are matched to the stored procedure by their position All parameters must have a value Overloaded procedures are determined by the number of parameters
Retrieving return codes

In nested stored procedures, the RETURN statement is used to immediately terminate an SQL procedure by returning the flow of control to the caller of the stored procedure. The RETURN statement can also pass an INTEGER value back to the calling stored procedure. If no value has been provided, the default value is 0. DB2 supports the GET DIAGNOSTIC statement to obtain information about a previously executed CALL statement as the listing below illustrates.
GET DIAGNOSTICS ret_code = DB2_RETURN_STATUS;
The following examples illustrate how to use RETURN and the GET DIAGNOSTICS statements. For example, suppose you have two different stored procedures: Listing 9. Different stored procedures
CREATE PROCEDURE TEST1(out v1 int)
developerWorks
begin set v1 = 10; return; end CREATE PROCEDURE TEST2(out v1 int) begin set v1 = 5; return 2; end
Now, call those stored procedures and check the respective DB2_RETURN_STATUS: Listing 10. Calling stored procedures and checking DB2_RETURN_STATUS
CREATE PROCEDURE NEST_DIAGN (out ret_code1 int, out ret_code2 int ) P1: BEGIN DECLARE val1 INT default 0; call test2(val1); GET DIAGNOSTICS ret_code1 = DB2_RETURN_STATUS; call test1(val1); GET DIAGNOSTICS ret_code2 = DB2_RETURN_STATUS; END P1
If you execute the NEST_DIAGN stored procedure from the DB2 command line, you get the following results: Listing 11. Result of executing the NEST_DIAGN stored procedure from the DB2 command line
C:\Program Files\IBM\SQLLIB\BIN>db2 call nest_diagn(?,?) Value of output parameters -------------------------Parameter Name : RET_CODE1 Parameter Value : 2 Parameter Name : RET_CODE2 Parameter Value : 0 Return Status = 0
Please note that you need to DECLARE a variable that will be accepting the value from DB2_RETURN_STATUS.
Sharing data between stored procedures

The previous examples show how stored procedures can share data using parameters and the RETURN statement. Now, let's examine how 2 (or more) stored procedures can share the same result set from a cursor.
developerWorks
Procedure result_from_cursor gets a name, job description, commission and location for each worker from the STAFF and ORG tables for a particular department: Listing 12. Example of procedure to return result set
CREATE PROCEDURE result_from_cursor (deptin int) DYNAMIC RESULT SETS 1 P1: BEGIN -- Declare cursor DECLARE cursor1 CURSOR WITH RETURN FOR SELECT a.name, a.job, COALESCE(a.comm,0), b.location FROM staff a, org b where a.dept = b.deptnumb AND a.dept = deptin; OPEN cursor1; END P1
For example, for department 51, you get the following result set: Listing 13. Result set for department 51
NAME --------Fraye Williams Smith Lundquist Wheeler JOB COMMISSION LOCATION ----- --------------- ------------Mgr 0.00 Dallas Sales 637.65 Dallas Sales 992.80 Dallas Clerk 189.65 Dallas Clerk 513.30 Dallas
Now you want to use the result set from this stored procedure (without storing it in temporary or permanent table) in another stored procedure. DB2 permits an outer stored procedure to use a result set from an inner one. Here is what you need to do: Declare a result set locator using the following syntax: DECLARE rs_locator_var1 RESULT_SET_LOCATOR VARYING; Associate this result set locator with the calling procedure: ASSOCIATE RESULT SET LOCATOR( rs_locator_var1) WITH PROCEDURE proc_called; Allocate the cursor that points to the result set from the calling procedure: ALLOCATE cursor1 CURSOR FOR RESULT SET rs_locator_var1; The following example demonstrates all those methods:
developerWorks
Listing 14. Using result set from nested procedure

CREATE PROCEDURE Use_nested_cursor (deptin int, OUT tot_dept_comm DEC(12,2)) BEGIN DECLARE DECLARE DECLARE DECLARE sqlcode int default 0; v_comm DECIMAL(12,2) DEFAULT 0.0; v_name, v_location varchar(20); v_job char(6);
DECLARE LOC1 RESULT_SET_LOCATOR VARYING; SET tot_dept_comm = 0; CALL result_from_cursor(deptin); ASSOCIATE RESULT SET LOCATOR( LOC1) WITH PROCEDURE result_from_cursor; ALLOCATE C1 CURSOR FOR RESULT SET LOC1; FETCH FROM C1 INTO v_name,v_job,v_comm,v_location; WHILE sqlcode = 0 DO SET tot_dept_comm = tot_dept_comm + v_comm; FETCH FROM C1 INTO v_name,v_job,v_comm,v_location; END WHILE; END
Now, if you execute this stored procedure with department "51" as the input parameter, you get the total department commission: Listing 15. Results when department 51 is an input parameter
> call use_nested_cursor (51,?) Value of output parameters -------------------------Parameter Name: TOT_DEPT_COMM Parameter Value: 2333.40
Sharing data with global variables

DB2 supports session global variables. A session global variable is associated with a specific session, is global for each stored procedure in that session, and contains a value that is unique to that session. The following diagram shows the syntax for the session global variable: Listing 16. CREATE VARIABLE syntax
CREATE VARIABLE var_name DATATYPE [DEAFULT value];
Please note that the session global variable is declared outside of a stored
developerWorks
procedure, just like any other database object. The following script demonstrates the use of global variables: Listing 17. Use of global variables
CREATE VARIABLE global_var_count INTEGER default 0; CREATE PROCEDURE project_count (IN var_respemp CHAR(6)) BEGIN SELECT COUNT(*) INTO global_var_count FROM project WHERE respemp = var_respemp; END CREATE PROCEDURE PROJECT_STATUS (IN p_respemp CHAR(6),OUT p_new_status CHAR(20)) BEGIN CALL project_count(p_respemp); IF global_var_count > 2 THEN SET p_new_status = 'Maximum projects' ; ELSE SET p_new_status = 'Available'; END IF; END
Section 5. Testing and deploying stored procedures

DB2 supports the command line processor (CLP), which is an interface to deploy (build) and test (execute) stored procedures. The user building the stored procedure should satisfy the following requirements: Must have the privileges required to execute the CREATE PROCEDURE statement Must have the privileges to execute all SQL statements in the stored procedure All database objects (example, tables, views, functions, other procedures) that are referenced in this SQL procedure should exist in the database A successful database connection must be established from the CLP (this can be achieved by using the following db2 command : db2 connect to sample user userid using password ) Each statement in an SQL procedure requires a statement terminator. The default is
developerWorks
semicolon (;). You need to select an alternative termination character to be able to create an SQL procedure in a script for the CLP to know where your SQL procedure is terminated. Most commonly used termination characters are the "at" (@) and exclamation (!) characters. So now write a script that contains a simple SQL procedure and put the "@" termination character at the end: Listing 18. Simple SQL procedure with @ termintor at end
CREATE PROCEDURE NUMBER_OF_ORDERS ( in_status varchar(10), in_date DATE, out num_of_order int) ------------------------------------------------------------------------- SQL Procedure -----------------------------------------------------------------------P1: BEGIN declare v_number INTEGER DEFAULT 0; SELECT count(poid) INTO v_number FROM PURCHASEORDER where ucase(status) = ucase(in_status) and orderdate < in_date; SET END P1 @ num_of_order = v_number;
This script is saved as file myscript.db2. To build the stored procedure number_of_orders from the DB2 CLP, you need to execute the following command:
db2 -td@ -vf myscript.db2
The general syntax for this CLP command is as follows:

db2 -td <terminating-character> -vf <CLP-script-name>
Note that the option -td indicates that the CLP terminator default is to be reset with the corresponding terminating character. The -vf option indicates that the CLP's optional verbose (-v) option is to be used, which causes each SQL statement or command in the script to be displayed on the screen as it is executed, along with any output that results from its execution. The -f option indicates that the target of the command is a file. Now it's time to execute (or test) this stored procedure from the CLP. To do that you need to run the following command:
developerWorks
db2 call number_of_orders('Shipped',current date, ?)
Figure 3. Testing procedure from CLP
Please note that you need to put a value for each input parameter and place a "?" (question mark) for each output parameter. But how would you know that the return value of 5 is correct? As this stored procedure is simple and only has one SQL statement, you can execute this statement from the CLP by putting input parameters directly into the WHERE clause as Listing 19 illustrates: Listing 19. SQL statement from procedure
SELECT count(poid) FROM PURCHASEORDER WHERE ucase(status) = 'SHIPPED' AND orderdate < CURRENT DATE;
Figure 4. Running this SQL Query from CLP
As you can see, you get the same result. With more complex stored procedure testing it could be a more time consuming task. You can use the IBM Data Studio tool to help you debug stored procedures.
developerWorks
Section 6. Securing SQL procedures

Authorizations
There are basically two types of authorization that needs to be considered for SQL procedures: The stored procedure definer is the user who actually creates the stored procedure. The stored procedure invoker is the user who invokes or calls the stored procedure. In order to create an SQL procedure, the userid performing the task needs to have BINDADD authority on the database and either IMPLICIT_SCHEMA on the database (if the schema for the stored procedure does not already exist), or CREATE_IN on the schema (if the schema for the stored procedure does already exist). They would also need to have all the necessary privileges to perform the SQL that is defined in the stored procedure body. In order to invoke or call an SQL procedure, the userid performing the task needs to have EXECUTE privilege on the stored procedure. The userid who created the SQL procedure implicitly gets EXECUTE privilege and the GRANT EXECUTE privilege. Either DBADM or SYSADM authority also allows a user to create or invoke an SQL procedure. It is generally recommended that a database administrator (DBA) is the one who creates the stored procedure for an application developer who may need to be able to invoke it.
SQL access levels in SQL procedures

There are four SQL access levels used for SQL statements that can control what type of SQL statements the SQL procedure can define. They are used to provide information to the database manager so that the statement can be executed safely by the database manager. The SQL access levels that can be used are: NO SQL: no SQL statement can exist in the stored procedure CONTAINS SQL: no SQL statement can modify or read data in the stored procedure
developerWorks
READS SQL: no SQL statement can modify data in the stored procedure MODIFIES SQL: SQL statements can both modify or read data in the stored procedure The default setting for SQL procedures is MODIFIES SQL. The SQL access level can also determine what kind of stored procedure can be invoked from within that stored procedure. A stored procedure cannot call another stored procedure that is set with a higher SQL data access level. As an example, a stored procedure defined with CONTAINS SQL can invoke a stored procedure that is defined with either CONTAINS SQL or NO SQL. That same stored procedure cannot invoke another stored procedure that is defined with READS SQL DATA or MODIFIES SQL. The SQL access level can be specified during the CREATE PROCEDURE statement.
Encrypting SQL procedures

Moving SQL procedures from one server to another server is a common task. For example, a vendor may want to package up their SQL procedure and send that package to their client. If the vendor wants to hide or encrypt the stored procedure contents from their client, they can do that via the PUT ROUTINE and GET ROUTINE commands. GET ROUTINE is a DB2 command that extracts an SQL procedure from the database and converts it into a SAR (SQL Archive) file, which can then be sent to the client. Listing 20. GET ROUTINE command syntax
>>-GET ROUTINE--INTO--file_name--FROM--+----------+-------------> '-SPECIFIC-' >----PROCEDURE----routine_name--+-----------+------------------>< '-HIDE BODY-'
The HIDE BODY clause on the GET ROUTINE command ensures that the body of the SQL procedure is not extracted, thus encrypting the stored procedure. PUT ROUTINE is a DB2 command that creates the SQL procedure in the database, given the SAR file that was extracted via GET ROUTINE.
developerWorks
Listing 21. PUT ROUTINE command syntax

>>-PUT ROUTINE--FROM--file-name---------------------------------> >--+-------------------------------------+--------------------->< '-OWNER--new-owner--+---------------+-' '-USE REGISTERS-'
Section 7. Conclusion
This tutorial has introduced you to a number of ideas that you will see on the DB2 9.5 Database Developer Certification Exam (735). The material in this tutorial primarily covers the objectives in Section 2 of the test, which is entitled "SQL Procedures". In this tutorial, you've learned about the DB2 stored procedure and how your application can benefit from using the SQL procedure. You've seen how to design your procedures using SQL PL and how to build and test them. This tutorial introduced the idea of nested procedures and showd you how to invoke them and share data between the procedures. Learning how to use these stored procedures allows you to integrate complex business logic into your overall database application.
developerWorks
Resources
Learn Read Part 1 of the series, "SQL Procedure Language," to learn about SQL Procedure Languag, including a variable, condition, and handler declaration, flow of control and iterative statements, as well as an error-handling mechanism. Part 3 of the series, "DB2 SQL functions," introduces you to user-defined functions and walks you through the basic steps used to construct user-defined functions. This tutorial also introduces you to the structure of SQL functions and covers the ins and outs of SQL function development. Part 5 of the series, "Advanced SQL features," learn about IBM DB2 temporary tables, ADMIN_CMD procedure, savepoints and other advanced SQL features. Visit the Test 735: DB2 9.5 SQL Procedure Developer page to get comprehensive resources related to the exam. The DB2 Family Fundamentals tutorial series gives you the resources you need to ace the DB2 Family Fundamentals test. Visit the developerWorks resource page for DB2 for Linux, UNIX, and Windows to read articles and tutorials and connect to other resources to expand your DB2 skills. Learn about DB2 Express-C, the no-charge version of DB2 Express Edition for the community. The DB2 9 for z/OS Stored Procedures: Through the CALL and Beyond IBM Redbook contains information about SQL Procedures. DB2 v9.5 Information Center: Learn more about DB2 SQL procedures. Get products and technologies Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2, Lotus, Rational, Tivoli, and WebSphere. Download a free trial version of DB2 9 for Linux, UNIX, and Windows. Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2 Express Edition for the community that offers the same core data features as DB2 Express Edition and provides a solid base to build and deploy applications. Discuss Participate in the discussion forum for this content.
developerWorks
Check out developerWorks blogs and get involved in the developerWorks community.
About the authors

Marina Greenstein Marina Greenstein is an Executive IT Software Specialist with the IBM Database Migration Team. She is an IBM Certified Solutions Expert who joined IBM in 1995 with experience in database application architecture and development. During the 13 years Marina has been with the DB2 Migration Team, she has assisted customers in their migrations from Microsoft SQL Server, Sybase, or Oracle databases to DB2. She has presented migration methodology at numerous DB2 technical conferences and at SHARE. She is also the author of multiple articles, white papers and IBM Redbooks about DB2 migration.
Shakeb Shere Shakeb Shere is a certified IBM DB2 Universal Database Application Developer. He has worked for the IBM DB2 technical support team for over 8 years, and has in-depth knowledge in all forms of application development support for DB2 including stored procedure support. He currently focuses his support in CLI, ODBC, .NET and OLEDB, and currently works in the Advanced Support Common Client Technologies team for DB2 Universal Database on Linux, UNIX, and Windows.

DB2 9.5 SQL Procedure Developer Exam 735 Prep, Part 2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DB2 9.5 SQL Procedure Developer Exam 735 Prep, Part 2

Uploaded by

Copyright:

Available Formats

DB2 9.

Section 1. Before you start

About this tutorial

Section 2. Stored Procedures

Advantages of using stored procedures

Limitations of stored procedures

Differences between external stored procedures and SQL stored procedures

Section 3. SQL procedure structure

structure of an SQL procedure: Listing 1. Structure of an SQL procedure

ATOMIC and NOT ATOMIC compound SQL

Compound SQL and scope of variables

Section 4. Nested stored procedures

Retrieving return codes

Sharing data between stored procedures

Listing 14. Using result set from nested procedure

Sharing data with global variables

Section 5. Testing and deploying stored procedures

The general syntax for this CLP command is as follows:

db2 call number_of_orders('Shipped',current date, ?)

Figure 3. Testing procedure from CLP

Figure 4. Running this SQL Query from CLP

Section 6. Securing SQL procedures

SQL access levels in SQL procedures

Encrypting SQL procedures

Listing 21. PUT ROUTINE command syntax

About the authors

You might also like