× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 3/12/2013 4:15 PM, CRPence wrote:
On 12 Mar 2013 12:07, fbocch2595 wrote:
Any idea how to get details of how many records were deleted when
using RUNSQL in batch in a CLP? That would be nice.

As noted in a prior discussion, write a program [even a very dynamic
REXX would do] to get the SQLERRD(3) of the SQLCA to identify the number
of rows deleted, instead of using such a generic SQL utility.

What I usually do is DSPFD before and after the RUNSQL.

If knowing what the upcoming DELETE statement would delete is
considered to be sufficiently accurate, then by using the CREATE VIEW
method, the CLP can have a DCLF to read the VIEW to learn the answer.
And to review just the count of rows to be deleted instead of the actual
rows to be deleted, that is easily done by creating another VIEW over
the first. For example:

DCLF DLT_COUNT /* create table qtemp/dlt_count (dlt_count dec(10)
not null ; or whatever required to get rcdfmt lvlid to match the VIEW */
RUNSQL SQL('create view qtemp/dlt_from as ( select * from t18pf
where joentt = ''CA'' and jojob = ''QZLSFILET'' and jopgm = ''QLESPI''
)' ) COMMIT(*NONE)
RUNSQL SQL('create view qtemp/dlt_count as ( select dec(count(*),
10) as dlt_count from qtemp/dlt_from)')
RCVF /* CL var &DLT_COUNT will now have the value of the number of
rows matching the WHERE clause of the upcoming DELETE; i.e. the
where-clause encapsulated in the SELECT of the first CREATE VIEW */
RUNSQL SQL('delete from qtemp/dlt_from') COMMIT(*NONE)
RCVF /* force the DLT_COUNT file to close */
MONMSG CPF0864 EXEC(rcvmsg (*same (*)) *pgmq *excp *none 0 rmv(*yes))
RUNSQL SQL('drop view qtemp/dlt_from cascade)')

As Chuck notes, this depends on knowing what the upcoming DELETE would
delete. Implied and important is knowing that no other process will be
deleting records in parallel with this process.

I'm rarely the only person on the machine, so I ended up writing an RPG
program to do the delete and report on the rows removed. I had to keep
a running history of what happened to my file, so I log adds, changes
and deletes to a summary file, including who and when. I could extract
all that from a journal receiver but it started out as a simple request
that just kept growing... :-)
--buck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.