Transaction Processing: Retrieving Query Results.  Read Part 1 here and Part 2 here.

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

When an SQL statement other than the SELECTstatement is executed, the only additional processing that might be performed is a check of the return code produced to verify the statement executed as expected. Or, a check to determine how many rows were affected by the operation. However, when a SELECTstatement (i.e., a query) is executed, any results that might have been produced will typically need to be retrieved and processed. With the ibm_db library, all the query results produced can be copied to a dictionary, tuple, or both (by calling the ibm_db.fetch_assoc(), ibm_db.fetch_tuple(), or ibm_db.fetch_both() API).Alternately,theibm_db.fetch_row()API can be used to advance the cursor to the next row (or move the cursor to a specific row) in a result set, and the ibm_db.result()API can be used to copy data from individual columns in that row to application variables.

When the ibm_db_dbi library is used, one or more records can be retrieved and copied to a tuple by executing the .fetchone(), .fetchmany(), or .fetchall() Cursor object method.

The following pseudo-source code example illustrates how ibm_ db.fetch_tuple() API in the ibm_db Python library might be used to retrieve data from a result set:

#! /usr/bin/python3

# Load The Appropriate Python Modules

import ibm_db

# Define And Initialize The Appropriate Variables

...

record = False

# Construct The String That Will Be Used To Connect

# To A Database, Then Establish A Connection

...

# Define The SQL Statement To Be Executed

sqlStmt = "SELECT deptname FROM department "

sqlStmt += "WHERE admrdept = 'A00'"

# Execute The SQL Statement Just Defined

results = ibm_db.exec_immediate(connID, sqlStmt)

# As Long As There Are Records In The Result Set, ...

noData = False

while noData is False:

# Retrieve A Record And Store It In A Tuple

record = ibm_db.fetch_tuple(results)

# If There Are No More Records, Exit The Loop

if record is False:

noData = True

# Otherwise, Display The Data Retrieved

else:

print(record[0])

...

The next pseudo-source code example illustrates how the .fetchall() Cursor object method could be used to retrieve data from a result set if the ibm_db_dbi Python library were used instead:

#! /usr/bin/python3

# Load The Appropriate Python Modules

import ibm_db_dbi

# Define And Initialize The Appropriate Variables

...

record = False

# Construct The String That Will Be Used To Connect

# To A Database, Then Establish A Connection

...

# Retrieve The Cursor Object That Was Created For

# The Connection Object

if not connID is None:

cursorID = connID.cursor()

# Define The SQL Statement To Be Executed

sqlStmt = "SELECT deptname FROM department "

sqlStmt += "WHERE admrdept = 'A00'"

# Execute The SQL Statement Just Defined

if not cursorID is None:

cursorID.execute(sqlStmt)

# Retrieve All Of The Records Returned

# And Store Them In A Python Tuple

results = cursorID.fetchall()

# Print Every Record Returned

for value in results:

print("{:24}" .format(value[0]))

...

Transaction Processing: Obtaining Result Set Information

If a SELECT statement is hard-coded into an application, the structure of the result set that will be produced is typically known in advance. However, if the SELECT statement used is created at application run time, you may need to acquire this information before you can process the results. With the ibm_db library, information about a result set can be obtained by executing any of the following APIs:

• num_fields()
• field_name()
• field_num()
• field_type()
• field_width()
• field_display_size()
• field_precision()
• field_precision()

When the ibm_db_dbi library is used, similar information can be obtained by examining the contents of the .description Cursor object attribute. The following pseudo-source code example illustrates how this attribute can be examined to obtain result set column information:

#! /usr/bin/python3

# Load The Appropriate Python Modules

import ibm_db_dbi

# Define And Initialize The Appropriate Variables

...

# Construct The String That Will Be Used To Connect

# To A Database, Then Establish A Connection

...

# Retrieve The Cursor Object That Was Created For

# The Current Connection Object

if not connID is None:

cursorID = connID.cursor()

# Define The SQL Statement To Be Executed

sqlStmt = "SELECT * FROM department "

sqlStmt += "WHERE admrdept = 'A00'"

# Execute The SQL Statement Just Defined

if not cursorID is None:

cursorID.execute(sqlStmt)

# Retrieve Attribute Information For Every Column

# In The Result Set Produced By The Statement

colInfo = cursorID.description

# Display Column Name And Data Type Information

x = 0

for record in colInfo:

print("Column name          : ", end="")

print(colInfo[x][0])

dataTypes = colInfo[x][1]

typeNames = []

for type in dataTypes:

typeNames.append(type)

print("Data type name(s)          : ", end="")

print(typeNames[0])

del typeNames[0]

for type in typeNames:

print(' ' * 27, end="")

print("{}" .format(type))

# Increment The x Variable And Print A Blank Line

x += 1

print()

...

Transaction Processing: Terminating the Current Transaction

You may recall that in Chapter 2, “Structured Query Language,” we saw that a transaction (also known as a unit of work) is a sequence of one or more SQL operations that are grouped together as a single unit, usually within an application process. Transactions are important because the initiation and termination of a single transaction defines points of data consistency within a database. Either the effects of all operations performed within a transaction are applied to the database and made permanent (committed), or, they are backed out (rolled back) and the database is returned to the state it was in before the transaction began.

When it comes to managing transactions, Python applications can be configured such that they run in one of two modes: auto-commit mode or explicit-commit mode. When auto-commit mode is used, every SQL operation performed is treated as a complete, individual transaction that is automatically committed as soon as it is successfully executed. When explicit-commit mode is used, transactions are started implicitly the first time an application connects to a data source or the first time an SQL operation is performed after a previously running transaction has been terminated. With Python applications, such transactions are explicitly ended when the ibm_db.commit() API or ibm_db.rollback() API is executed (ibm_db library) or the .commit() or .rollback() Connection object method is invoked (ibm_db_dbi library).

When the ibm_db library is used, auto-commit mode is enabled by default. However, the actual commit mode used can be controlled by assigning the value ibm_db.SQL_AUTOCOMMIT_ON or ibm_db.SQL_ AUTOCOMMIT_OFF to the ibm_db.SQL_ATTR_AUTOCOMMIT connection option at the time a connection to a Db2 database is made. Alternatively, the ibm_db.autocommit() API can be used to change the commit mode used after a database connection has been established. When the ibm_db_ dbi library is used, explicit-commit is the only commit mode available.

Consequently, every transaction must be terminated by executing the .commit() or .rollback() method of the Connection object that was returned when the ibm_db_dbi.connect() API was executed. Regardless of which type of commit mode is used, all transactions associated with a specific database connection should be completed before that connection is terminated.

When running in explicit-commit mode, the following should be taken into consideration:

• Only the current, active transaction can be committed or rolled back; therefore, all dependent SQL operations should be performed within the same
• Various table-level and row-level locks can be held by a single transaction and these locks are not released until the transaction is Consequently, other concurrently running transactions may be prevented from getting access to the locked data until the transaction holding the locks ends.
• Any transaction that has not been committed or rolled back before an application ends will be “lost” and its effects will be discarded. The same is true if a system or application failure Therefore, transactions should be ended as soon as reasonably possible.

When defining transaction boundaries, keep in mind that all resources associated with a transaction—with the exception of those coupled with a held cursor—are released. However, prepared SQL statements and parameter marker bindings are maintained from one transaction to the next. Therefore, once an SQL statement has been prepared, it does not need to be prepared again—even after a commit or rollback operation is performed—provided it remains associated with the same IBM_DBStatement or Cursor object.

More transaction processing awaits in Part 4, coming soon in an upcoming issue of MC TNT. Can't wait?  You can pick up Roger Sander's book, QuickStart Guide to Db2 Development with Python, at the MC Press Bookstore Today!

Roger E. Sanders is a Principal Sales Enablement & Skills Content Specialist at IBM. He has worked with Db2 (formerly DB2 for Linux, UNIX, and Windows) since it was first introduced on the IBM PC (1991) and is the author of 26 books on relational database technology (25 on Db2; one on ODBC). For 10 years he authored the “Distributed DBA” column in IBM Data Magazine, and he has written articles for publications like Certification Magazine, Database Trends and Applications, and IDUG Solutions Journal (the official magazine of the International Db2 User's Group), as well as tutorials and articles for IBM's developerWorks website. In 2019, he edited the manuscript and prepared illustrations for the book “Artificial Intelligence, Evolution and Revolution” by Steven Astorino, Mark Simmonds, and Dr. Jean-Francois Puget.

From 2008 to 2015, Roger was recognized as an IBM Champion for his contributions to the IBM Data Management community; in 2012 he was recognized as an IBM developerWorks Master Author, Level 2 (for his contributions to the IBM developerWorks community); and, in 2021 he was recognized as an IBM Redbooks Platinum Author. He lives in Fuquay Varina, North Carolina.

---

MC Press books written by Roger E. Sanders available now on the MC Press Bookstore.

		QuickStart Guide to Db2 Development with Python Discover how Python, SQL, and Db2 can successfully be used with each other. List Price $9.95 Now On Sale
		DB2 10.5 Fundamentals for LUW (Exam 615) Don't even think about attempting to take the DB2 Fundamentals exam without this indispensable study guide. List Price $79.95 Now On Sale
		DB2 10.1 Fundamentals (Exam 610) Let one of the world's leading DB2 authors and a participant in the exam development help you succeed. List Price $79.95 Now On Sale
		Artificial Intelligence: Evolution and Revolution Operational AI has become available to the masses, setting the wheels in motion for a worldwide AI revolution that has never been seen before. List Price $16.95 Now On Sale
		DB2 10.5 DBA for LUW Upgrade from DB2 10.1: Certification Study Notes Here's everything you need to know to take and pass Exam 311, complete with a practice exam and study key. List Price $21.95 Now On Sale
		From Idea to Print Here's everything you need to know to turn your technical knowledge and expertise into a published article or book. List Price $49.95 Now On Sale
		DB2 9 Fundamentals (Exam 730) Use this review before taking the test to prove you've mastered the basics of DB2 9. List Price $59.95 Now On Sale
		DB2 9 for Linux, UNIX, and Windows Database Administration (Exam 731) Use this indispensable study guide to prepare to take, and pass, Exam 731. List Price $64.95 Now On Sale
		DB2 9.7 for Linux, UNIX, and Windows Database Administration (Exam 541) Get ready to take the DB2 9.7 certification exam with this handy study guide. List Price $21.95 Now On Sale
		DB2 9 for Linux, UNIX, and Windows Advanced Database Administration (Exam 734) Review all exam topics and take the included practice test to be sure you're ready on testing day. List Price $64.95 Now On Sale
		DB2 9 for Linux, UNIX, and Windows Database Administration Upgrade (Exam 736) Prep for success with the master of DB2 certification study guides! List Price $34.95 Now On Sale
		Data Fabric: An Intelligent Data Architecture for AI This book explains the concepts and values that a data fabric approach can deliver to both technical and business communities. List Price $19.95 Now On Sale

Also Read

Node.js on IBM i: System Access and DB2 Database Access

Node.js on IBM i: Vexing Versions

Kisco U - Journaling Data Areas