14
Mon, Oct
6 New Articles

TechTip: Handling SQL Return Codes, Part I

SQL
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

In a previous article, I demonstrated that treating SQLCOD as a two-value field, just like a native IO on/off indicator has some inherent dangers. In this article, I encourage you to use SQLSTT instead of SQLCOD and I provide a list of the SQLSTT values that commonly occur in business programming. Then I show you that it's easy to stringently check all SQL return codes.

SQLSTT vs. SQLCOD

SQLSTT (SQL State) and SQLCOD (SQL Code) return largely the same information about the last executed SQL statement, but they use different formats. I prefer to use the SQLSTT field rather than SQLCOD for a couple of reasons:

  • SQLCOD = 0 means success, but "success" may also be qualified by warnings in the SQLWRN field. If any of the warnings might significantly impact your program logic, you also have to check SQLWRN and its subfields. A SQLSTT of '00000' means unqualified success, and I find it more convenient.
  • SQLSTT codes are based on the ISO/ANSI SQL 1999 Core standard and are the same across all versions of DB2, so you also have more in common with your non-iSeries coworkers.

I code as meaningfully named constants the handful of SQLSTT values that are routinely checked. See Figure 1. Put these lines in a copy book if you want consistency in your shop. Use different meaningful names if you want, but for clarity, do use names.

*=== SQL State Constants ============================= 
d SQLSuccess      c                   '00000'         
d SQLNoData       c                   '02000'         
d SQLNoMoreData   c                   '02000'         
d SQLDupRecd      c                   '23505'         
d SQLRowLocked    c                   '57033'         

Figure 1: These are meaningfully named common SQLSTT values.

SQLSuccess says the SQL operation went off without a hitch, exactly as expected.

SQLNoData occurs when a SELECT statement does not find a qualifying row and thus returns no data ("No record found" in native IO).

SQLNoMoreData occurs when FETCHing from a cursor and you have come to the end of the results set ("End of file" in native IO).

SQLDupRecd occurs when you do an insert that fails a primary key constraint. (In native parlance, you have a unique key on the file and a record with this key already exists.)

SQLRowLocked occurs when you try to update a record, but someone else has it locked for update.

(Sharp-eyed readers will notice that SQLNoData and SQLNoMoreData have the same value, '02000'. I'm a bit of a perfectionist, and I think the code is more intuitive if both are available and used in the appropriate context.)

There are many SQL return codes, but in my experience, only this handful turns up routinely in the business programs that most of us regularly create. Treat these as a beginning set and add more as needed. Most, but not all, of the others indicate an error that should never occur and from which there is frequently no programmatic recovery.

Checking SQL Execution Success

Here's my general rule of thumb: Check for and have logic to handle the SQLSTT return codes you expect. If you get a return code you don't expect, do not ignore it; instead, take some diagnostic action with a common error handler.

I check SQLSTT after every executable SQL statement. Note that Set Option and Declare Cursor are not executable statements, and thus they do not set SQLSTT, so do not check after these statements.

My assumption is that environmental issues—such as setting library lists, file authority, and file availability—have been taken care of prior to my program. So, after an Open Cursor statement, the only return code I expect is success, and I route any other to a standard routine to handle unexpected SQL return codes. If the cursor is already open, trying to open it again will return an error. This means to me that I goofed and seriously need to review my program logic, so the standard error-handling routine is appropriate in this case.

Figure 2 has examples of non-executable and executable SQL statements that typically occur at the beginning of a program, and it shows return code checking after the executable open statement.

//=== Set SQL Options =================
exec sql set option datfmt=*iso,      
                    closqlcsr=*endmod;
                                       
//=== Cursor ==========================
exec sql declare DemoCursor cursor for 
         select                        
                   PROMO,              
                   FIRST,              
                   LAST                
         from      SQL_DEMOP           
         where     FIRST <= :MyDate    
               and LAST  >= :MyDate    
         order by  PROMO               
     ;                                 
                                       
//=== Initialization ==================
exec sql open  DemoCursor;             
if SQLSTT <> SQLSuccess;               
    SQLProblem('open DemoCursor');     
endif;  

Figure 2: Note SQLSTT not checked when statement is not executable.

When fetching the next row from the cursor, you generally expect to get either a row or an end-of-data indication. The FetchCursor subroutine in Figure 3 returns with one of two values: success and data is available, or no more data. Any other return code is unexpected and routed to the standard error-handling routine. A SELECT...INTO statement would be treated the same way if, as usually is the case, you are expecting only one row to be returned.

//--- FetchCur ------------------------------
// Get the next row from the cursor          
// Returns: SQLSuccess, with data            
//          SQLNoMoreData, no data returned  
begsr FetchCur;                              
exec sql fetch DemoCursor into               
               :MyPromo,                     
               :MyFirst,                     
               :MyLast                       
     ;                                       
if SQLSTT <> SQLSuccess                      
    and SQLSTT <> SQLNoMoreData;             
    SQLProblem('fetch DemoCursor');          
endif;                                       
endsr;

Figure 3: The Fetch subroutine returns only two SQLSTT values.

I then use FetchCur in a simple main program loop, as in Figure 4, confident that SQLSTT is really now a two-valued field.

//=== Main Logic ====================
exsr FetchCur;                       
dow SQLSTT = SQLSuccess;             
    // Program logic here;                     
    exsr FetchCur;                   
enddo;

Figure 4: Use FetchCur in your main program loop.

When I have read all rows from the cursor, I close it, treating the Close Cursor statement the same way as the Open Cursor—only success is acceptable. See Figure 5. This may appear unnecessary, because what can go wrong closing a cursor? So far, I have never had a production problem closing a cursor, but the checking is not a whole lot of code, and during testing it may highlight a logic error if you unintentionally close a cursor you never opened or try to close one twice.

//=== Termination =====================
exec sql close DemoCursor;             
if SQLSTT <> SQLSuccess;               
    SQLProblem('close DemoCursor');    
endif;                                 
*inlr = *on;

Figure 5: Close the Cursor and check for success.

The Standard Error-Handler

The SQLProblem function that takes care of unexpected return codes has appeared in all of the code samples above. What does it do? Due to space constraints, SQLProblem will be covered in a follow-up article. In that TechTip, I will also provide a skeleton program that you can clone to start coding many of your embedded SQL programs.

Sam Lennon is a Systems Analyst and iSeries geek at a major electronics retailer. He has worked on the AS400/iSeries/i5 platform for 16 years and no longer admits to how long he's been writing code.

Sam Lennon

Sam Lennon is an analyst, developer, consultant and IBM i geek. He started his programming career in 360 assembly language on IBM mainframes, but moved to the AS400 platform in 1991 and has been an AS400/iSeries/i5/IBM i advocate ever since.

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: