On November 11th, 2022, the SAP Support Required PTF Lists, formerly known as Information APARs, have been updated to include fix levels for the most recent security bulletins and other corrections. High Impact/Pervasive PTF groups, Db2 for i PTF groups and cumulative PTF packages were updated. The PTF lists can …

The Fall 2022 #IBMi #performance FAQ was published on November 2and is now live on the web.ibm.com/downloads/cas/… #IBMPower

– Steve Will (@Steve_Will_IBMi)07:12 – Nov 15, 2022

The #IBMi ODBC driver is now easier to install and update using either #Yum or #ACS. @alanseiden shows us how to do it: ow.ly/r4na50KH3lE #ODBC #Db2fori pic.twitter.com/QjmAMeSZeQ

– Seiden Group (@SeidenGroup)05:03 – Nov 15, 2022

 Last year, I highlighted the performance advantages of writing tableless queries with the SQL VALUES support. In the spirit of the upcoming US Thanksgiving holiday, I want to point out another reason developers can be thankful for the VALUES support in SQL.

The VALUES support comes in two flavors, VALUES & VALUES INTO, just like the SQL SELECT syntax. The VALUES INTO and SELECT INTO statements enable you to run a query that generates a single row and assign the values in that row to variables. While both statements provide the same capability, the VALUES INTO statement has the added advantage that it can be dynamically prepared and executed. This advantage is a big one for SQL developers because it allows you to implement a solution with less SQL code.

To help you understand why developers should be thankful for the dynamic SQL support of VALUES INTO, let’s look at the hoops you had to jump through prior to the VALUES support. Since the SELECT INTO statement could not be dynamically prepared, the only way to assign the results of a dynamic query to variables was through the usage of a dynamic SQL cursor. 

Let’s assume that a program needs to return the count of rows in a table (e.g., MYTABLE) and dynamic SQL is required because that table can reside in many different libraries. The SELECT version of this solution would look like the following set of code. First, the count query statement text is assembled and prepared. Next, a cursor for that prepared statement must be declared and then that cursor must be opened, fetched, and closed.

A lot of code and work to just run and save the results of a simple row count query. 

Now, let’s examine how the VALUES INTO statement provides for a simpler solution. The fact that this VALUES INTO implementation requires half as much code should make it clear why this is a preferred solution.

The VALUES INTO support enables the simple execution of a dynamic query without the coding overhead of using an SQL cursor.

The fewer lines that you have to code means less code that you have to test and maintain going forward. And those are great reasons to be thankful if you’re an SQL developer!