Showing posts with label query. Show all posts
Showing posts with label query. Show all posts

Wednesday, January 14, 2026

Another way to list files defined in Querys

After writing the post about Retrieving the print file name from a Query it struck me that I could use the same methodology to answer a question I have been asked on several occasions: Which Querys are using a particular file?

I cannot answer which Querys are using a file. I can list all the files that Querys are defined to use.

What are the steps I need to perform to get that information:

  1. Make a list of all the Querys in a particular library
  2. Print their definitions using PRINT_QUERY_DEFINITION
  3. Extract the file names from the spool file, and write them to an output file

I am going to show you how I manually executed the above steps. And then I will show a program I created to do the same thing.

First, I need to make a list of all the Querys in a library, MYLIB. I will use the OBJECT_STATISTICS SQL Table function.

01  SELECT OBJLIB,OBJNAME
02    FROM TABLE(QSYS2.OBJECT_STATISTICS('MYLIB','*QRYDFN','*ALL'))

Line 1: I only want the Query library and name in my results.

Tuesday, November 25, 2025

WRKQRY missing from IBM i 7.6

I had found that the Work Query command, WRKQRY, was not working on the IBM i 7.6 partition I have been using. I thought that, perhaps, Query had been uninstalled from the partition.

I have learned that IBM is aware of this issue, described as:

WRKQRY does nothing, even though the QU1 LPP is installed

There is a PTF to re-enable the command, that was release on November 19. As the latest Technology Refresh was released after this date, if you already applied IBM i 7.6 TR1 I would check if you have already installed this PTF.

The "Known Issues" page is here.

And the "Fix information" page for the correcting PTF, SJ05457, is here.

The Run Query command, RUNQRY, has been working.

 

This article was written for IBM i 7.6.

Wednesday, November 19, 2025

Retrieving the printer name from a Query

The question was posed if it possible to retrieve the name of printer that has been entered into a Query for all the Queries in a library?

I already knew how to retrieve the SQL statement from a Query. Alas, the information about the printer is not found that way.

After some searching I found a SQL procedure that will give me the information I need: PRINT_QUERY_DEFINITION. For some reason there is no mention of this in IBM's documentation portal. I found reference to it in the IBM Support portal.

PRINT_QUERY_DEFINITION generates a spool file that lists all the information about the Query, including the choice of output.

My scenario is that I want a list of the Queries in a library and which printers they are defined to use.

Not all Queries use printers. Some will only display, and others will output to an output file. For this example, I created four Queries. The files they are built over, fields selected, selection criteria, column formatting, etc. is irrelevant. All that matters is the output type. This can have three values:

  1. = Display the results on the screen
  2. = Direct the output to a spool file
  3. = Direct the output to an output file

Tuesday, July 26, 2022

Which files are used by a Query?

query files used

This is a question I am asked enough for me to want to write this so I can direct the askers here. The question is:

How can I discover the files used by all the Query/400 objects in a library?

The Query/400 object is called a Query Definition, and is the following object type: *QRYDFN

To generate a list of the files they use is a two-step process.

The first process is to create an output file that contains the data. I use the Display Program Reference command, DSPPGMREF, to generate the output file. If I wanted to list all the files used by all of the Query definitions in the library MYLIB I would use the following:

Wednesday, August 10, 2016

Changing column headings in output file

using sql to change names of fields or columns in output file produced by query

I am sure there are some who are going to criticize me for saying this, but I do use Query. While I do not use it for "production" reports, I do use it is a quick and easy way to check data, or even to generate a quick "one off" output file. Yes, I know I could use SQL to do the same, but sometimes it is just, in my opinion, quicker and easier to use Query.

One of the drawbacks of using Query are the Column Headings it produces for outfiles. If for example I join a file to itself and/or "define a result field" the Column Heading produced is unclear or outright confusing. Even if I go into the option to "Specify report column formatting" and change the Column Headings, I still get the original column headings in the outfile.

I could email myself/download the file and change the column headings in Microsoft Excel, but there must be an easy way to do it? Fortunately there is using SQL.

Wednesday, February 5, 2014

Soft coding parameters used by Query

query qryfile output printer

In the environment I work there are many programs that produce "download reports". There are not paper reports, but extracts of file(s) that are sent, via email, to the requestor. Most of these use a Query to gather information together.

Many are coded like this:

   RUNQRY  QRY(QUERY1)

Which means that when the Query is run it will use the files that are hard coded in the Query’s definition. Therefore, if I want to perform a test and use files in a testing library I have to change the Query.

Or if I want to change which file or library the output file is in I have to change the Query.

Fortunately, there is an easy way to overcome these issues by using the parameters in the RUNQRY command.

Friday, August 23, 2013

Changing name of Query/400 print file

I was asked a question about how to change the name of the spool file created by running Query/400.

The default print file for Query/400 output is QPQUPRFIL. The inquisitor wanted to change the name of the spool file to another which would allow the users to be able to identify it.

This can be achieved by using the OVRPRTF command.

Tuesday, August 20, 2013

Getting the SQL statement out of Query/400

I first learned about embedding SQL into RPG programs at a user group meeting many years ago. I could see it as a tool that would increase my productivity, but all I had was a paper copy of the slideshow that had been presented. The company I was working with had SQL loaded on their AS400 (IBM i), but none of their programmers used it. This was the time before Google, and I struggled to find resources about SQL especially about the different types of joins, etc.

Fortunately I stumbled across a way to retrieve the SQL statement from a Query/400 into a source member. Now I could build a Query close to what I want, then view the SQL to get an idea of how to make my own statement.

Friday, July 26, 2013

Query Engines: CQE versus SQE

I received an interesting message regarding the Passing parms to a Query post that I consider worth sharing.

Before I share the message I need to explain that there are two query engines on the IBM i (AS400): the Classic Query Engine (CQE) and the SQL Query Engine Engine (SQE). What runs through each engine is shown below:

Wednesday, July 24, 2013

Passing parms to a Query

Query/400 has always provides a quick and easy way to generate a report or create an output file. I have found that once they are built they never go away, as a programmer never has time, with all the demands on their time, to replace it with a RPG program.

If a Query joins several large files it can become a resource hog, taking away CPU power from normal daily interactive processing. The solution has always been to run Queries in batch.

Most people find that if they need to change the Query’s run parameters they use the Record Select parameter, RCDSLT(*YES), in the Run Query command, RUNQRY.

  RUNQRY QRY(QUERY_NAME) RCDSLT(*YES)

Of course this cannot be run in batch. Therefore, this Query, with its large joins, runs interactively, and the other users complain that the system is running slow.

But there is another way using the Start Query Management Query, STRQMQRY, command.