Calling Stored Procedures. Read Part 1, Part 2, and Part 3 of this series.

Editor's Note: This article is excerpted from chapter 6 of QuickStart Guide to Db2 Development with Python, by Roger Sanders.

If an application has one or more transactions that perform a relatively large amount of work with little or no user interaction, those transactions can be encapsulated and stored on the database server as a stored procedure. Stored procedures make it possible to perform data processing operations directly at the server, which typically is a high-performant computer that can provide quick, coordinated data access. More importantly, because a stored procedure is invoked by a single SQL statement (or API/Cursor object method), fewer messages have to be transmitted across the network—only the data that is actually needed at the client has to be sent across the wire.

Once a stored procedure has been created and registered with a Db2 database (using the CREATE PROCEDURE SQL statement), that procedure can be invoked, either interactively using a utility like the Db2 CLP, or from an application. Typically, stored procedures are invoked by executing the CALL SQL statement. However, with Python applications, the preferred way to invoke a stored procedure is by executing the ibm_db.callproc() API (if the ibm_db library is used), or the .callproc() Cursor object attribute (if the ibm_db_dbi library is used).

The following pseudo-source code example illustrates how ibm_ db.callproc() API in the ibm_db Python library might be used to execute a stored procedure:

#! /usr/bin/python3

# Load The Appropriate Python Modules

import ibm_db

# Define And Initialize The Appropriate Variables

...

pVals = (0.0, 0.0)

# Construct The String That Will Be Used To Connect

# To A Database, Then Establish A Connection

...

# Define An SQL Statement To Create A

# Stored Procedure

sqlStmt = "CREATE OR REPLACE PROCEDURE salary_stats "

sqlStmt += "(OUT maxSal DOUBLE, OUT minSal DOUBLE) "

sqlStmt += "DYNAMIC RESULT SETS 0 "

sqlStmt += "BEGIN"

sqlStmt += "SELECT MAX(salary) INTO maxSal "

sqlStmt += "FROM employee; "

sqlStmt += "SELECT MIN(salary) INTO minSal "

sqlStmt += "FROM employee; "

sqlStmt += "END"

# Execute The SQL Statement Just Defined

retCode = ibm_db.exec_immediate(connID, sqlStmt)

# Execute The Stored Procedure Just Created

results = ibm_db.callproc(connID, "salary_stats", pVals)

# Display The Values Returned By The Stored Procedure

print("Highest salary : $ ", end="")

print(results[1])

print("Lowest salary: $ ", end="")

print(results[2])

...

It’s important to note that a single stored procedure is capable of returning zero, one, or more result sets, depending on how it was designed. (If you look closely at the pseudo-source code example just presented, you will see a line that reads “DYNAMIC RESULT SETS 0”; this line tells Db2 the procedure will not return any result sets.) The ibm_db.next_result() API (if the ibm_db library is used), or the .nextset() Cursor object method (if the ibm_db_dbi library is used), can be used to initialize processing of the next result set available if a stored procedure returns more than one result set.

Terminating a Db2 Server or Database Connection

The last thing every Db2-based application must do before returning control to the operating system is terminate any Db2 server or database connections that have been established. When the ibm_db Python library is used, connections can be terminated by calling the ibm_db_dbi.close() API; when the ibm_db_dbi Python library is used, connections can be terminated by executing the .close() method of the Connection object that was returned when the ibm_db_dbi.connect() API was invoked.

Obtaining Information About a Data Source and Setting Driver Options

There may be times when it is necessary to obtain information about a Db2 client, server, or database an application is connected to. For this reason, all CLI/ODBC drivers must support a set of functions that can provide information about the capabilities of a driver and the driver’s underlying data source. And, because the Db2 CLI driver serves as the foundation for the ibm_db and ibm_db_dbi libraries, similar capability is available to Python applications that use the ibm_db library. (This functionality is NOT available with the ibm_db_dbi library.)

The ibm_db.client_info() and ibm_db.server_info() APIs can be used to obtain information about a Db2 client or server being used. And, metadata from a Db2 database’s system catalog can be obtained by executing any of the following APIs:

• tables()
• table_privileges()
• columns()
• column_privileges()
• special_columns()
• statistics()
• primary_keys()
• foreign_keys()
• procedures()
• procedure_columns()

Most data source drivers contain additional information that can be changed to alter the way in which a driver behaves for a particular application. This updatable information is referred to as driver attributes or options. And with the ibm_db library, two types of driver options are available: connection options and SQL statement options. Python applications can retrieve the value of the connection and statement options available by executing the ibm_db.get_option() API. And, they can change the value of select connection and statement options by calling the ibm_ db.set_option() API.

Diagnostics and Error Handling

Error handling is an important part of any application, and Python applications that interact with Db2 are no exception. At a minimum, a Db2- Python application should always check to see if an API or object method that was invoked was able to execute successfully. Often, this can be done by examining the API or object method’s return code. (For the most part, APIs in the ibm_db library return False or None if they fail to execute. If an object method in the ibm_db_dbi library fails to execute, an Error or subclass exception will typically be raised.) In either case, users should be notified that an error or warning condition has occurred and, whenever possible, they should be provided with sufficient diagnostic information to help them identify and correct the problem.

Although return codes can indicate that an error or warning condition occurred, they do not always provide an application (or developer or user) with specific information about what caused the error or warning to be generated. Because additional information about an error or warning condition is usually needed to resolve a problem, Db2 (as well as other relational database products) use a set of error message codes known as SQLSTATEs to provide supplementary diagnostic information for warnings and errors. SQLSTATEs are alphanumeric strings that are five characters (bytes) in length and have the format ccsss, where cc indicates the error message class and sss indicates the error message subclass.

Any SQLSTATE that has a class of 01 corresponds to a warning; any SQLSTATE that has a class of HY corresponds to an error that was generated by the Db2 CLI; and any SQLSTATE that has a class of IM corresponds to an error that was generated by the ODBC Driver Manager. (Because different database servers often have different diagnostic message codes, SQLSTATEs follow standards that are outlined in the X/Open CLI standard specification. This standardization of SQLSTATE values enables application developers to process errors and warnings consistently across different relational database products.)

Unlike return codes, SQLSTATEs are often treated as guidelines, and drivers are not required to return them. Consequently, most applications simply display them, along with any corresponding diagnostic message and native error code available. Loss of functionality rarely occurs with this approach because applications normally do not base programming logic on SQLSTATE values.

When the ibm_db library is used, SQLSTATE values associated with Db2 server or database connections can be obtained by executing the ibm_ db.conn_error() API. On the other hand, SQLSTATE values associated with SQL statements can be retrieved by executing the ibm_db.stmt_ error() API. Developers using the ibm_db_dbi library, however, will find that a different set of error codes are used to conform to the PEP 249 — Python Database API Specification. Consequently, SQLSTATE values are not available when this library is used.

SQLSTATE values alone may not be enough to help resolve a problem if an application user is unfamiliar with them. Therefore, two additional APIs that can be used to obtain Db2-specific error messages associated with connections and SQL statements are provided with the ibm_db library. These APIs are ibm_db.conn_errormsg() and ibm_db.conn_errormsg().

For examples of how to perform error handling using API return codes, as well as the error handling APIs just discussed, refer to the sample programs found in the IBM Db2-Python GitHub repository.

Enjoy this set of excerpts?  Want more?  You can pick up Roger Sander's book, QuickStart Guide to Db2 Development with Python, at the MC Press Bookstore Today!