Need SQL To do summary like Query/400

Question

The following SQL is not exactly what I need. In a query I am summing Line totals according to Part# and Date. This is an invoice history file. the user has a report that shows QTY sold by part# - but the file used there does not hold $amt. So I made a query that creates a temp file that breaks on Part# and date. Because the report selects by date. This sql is created by the RTVQMQRY. IT doesn't seem to summary.

SELECT                                                                   
  ALL       (((T02.IDSHP#*IDNTU$))), T02.IDDOCD, T02.IDINV#, T02.IDPRT#  
  FROM      DTALIB/OEIND1 T02 INNER JOIN                                 
            OKLIB/ICDET76OK T01                                          
  ON        T02.IDCOM# = T01.ITCOM#                                      
    AND     T02.IDIDC# = T01.ITTRN#                                      
  WHERE     IDDOCD >= 20130101                                           
  ORDER BY  004 ASC, 003 ASC, 002 ASC, 001 ASC                           

Answer 1

SQL is not a reporting tool. SQL is a language that asks for sets of data; typically either details or totals (GROUP BY). SQL will do totals if you specify GROUP BY WITH ROLLUP, but that doesn't apply here.

There are several approaches you can take.

1) Create a view or logical file that does the JOIN you've specified above. Then use Query/400 to generate the report you need, with totals.

2) Since SQL wants to return a set, return 2 sets and do a UNION. The first set is the details and the second set is the total. There's a bit of a trick, in that each column in the two sets needs to be the same data type, but something like this should work:

SELECT                                                                   
  ALL       'D', T02.IDSHP#*IDNTU$, T02.IDDOCD, T02.IDINV#, T02.IDPRT#  
  FROM      DTALIB/OEIND1 T02 INNER JOIN                                 
            OKLIB/ICDET76OK T01                                          
  ON        T02.IDCOM# = T01.ITCOM#                                      
    AND     T02.IDIDC# = T01.ITTRN#                                      
  WHERE     IDDOCD >= 20130101
union
SELECT                                                                   
  ALL       'T', sum(T02.IDSHP#*IDNTU$), ' ', 0, 0
  FROM      DTALIB/OEIND1 T02 INNER JOIN                                 
            OKLIB/ICDET76OK T01                                          
  ON        T02.IDCOM# = T01.ITCOM#                                      
    AND     T02.IDIDC# = T01.ITTRN#                                      
  WHERE     IDDOCD >= 20130101
ORDER BY  1, 5, 4, 3, 2

See the second SELECT? It has the same columns as the first, and hopefully, the same data types. If your invoice number or part numbers are character columns, then use characters (' ') rather than numbers (0). Just to make sure the total comes AFTER the detail, I added another column that will sort the total last.

From a style perspective, I'd use meaningful correlation names. T01 and T02 aren't as easy to read (and debug in the future) as, say, INV and DTL. Yes, that's what RTVQMQRY generated, but you don't need to keep them that way.

Answer 2

Nooooooooo.... Please don't use Query/38 (oh yeah, sorry, they renamed it to Query/400), which has been around and probably unimproved since 1982.

QM Query is a reporting tool that will help you format your reports, have multi-level breaks, allows a prompted interface similar to Query/400. You have found how to retrieve the old query into QM Query source. With STRQM you can work with the query itself in prompted mode (as Query/400 users will be most comfortable with) initially if you wish, or in SQL mode, which I recommend for becoming more comfortable with SQL. This helped me learn quite a few years ago.

You can define a QM Query Form, which will give you the level breaks and other formatting that you may want. In this mode, you can let the Form do the breaks and summarizing, while your SQL need only supply the detail lines of the report.

Answer 3

The suggestion to use QM Query is part of the likely solution. (Query/400 probably should never be used.) You're already partly doing that because you used RTVQMQRY to generate the SQL 'query'. But next you'd need to run RTVQMFORM to generate the reporting piece out of your existing query. The reporting is where the report summaries would be created.

As Buck showed, it's technically possible to generate summary rows purely within the query itself. But even that still needs report formatting.