Re: SQL and trigger s -- MIDRANGE-L

Finally getting to try this. I wanted to use the file method. I
neglected to include an additional parameter in my example.

Needs to be:
DELETE FROM SECWRK/BSYSQSP2 WHERE QSSEC2 <> '@ADR' AND
QSFN01 = 'BOC151' AND QSSW01 = 'E'

Other values for QSFN01 have either no value for QSSW01 or some other
single character.

But, for the single situation above, joblog shows this:
Member BSYSQSP2 in SECWRK not journaled to journal *N.
BSYSQSP2 not valid for operation.
RUNSQLSTM command failed.
SQL0910 received by.....

I was working on a copy of the file. I copied the live file to the
test environment. All journalling is correct. It runs with no error.

But, the spool file has this:

SQL0100 Position 1 Row not found for DELETE
SQL7960 Commit complete

I remember seeing a message stating xx rows effected when I have used
STRSQL. The above suggests to me that it didn't work. I have checked
the field names and they are in the file.

Obviously, I am missing something else.

I can hear Homer Simpson coming.......

Thanks.

John McKee

On Mon, Oct 29, 2012 at 1:32 PM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

SQL DELETE without a where clause theoretically means delete each row
one by one.

Originally, this is how the DB worked, meaning SQL deletes were far
slower than CLRPFM for example.

At v5r3 (?) IBM enhanced the SQL delete processing, from the manual:
An SQL DELETE statement that does not contain a WHERE clause will
delete all rows of a table. In this case, the rows may be deleted
using either a clear operation (if not running under commitment
control) or a change file operation (if running under commitment
control). If running under commitment control, the deletes can still
be committed or rolled back. This implementation will be much faster
than individually deleting each row, but individual journal entries
for each row will not be recorded in the journal. This technique will
only be used if all the following are true:
v The target table is not a view.
v A significant number of rows are being deleted.
v The job issuing the DELETE statement does not have an open cursor on
the file (not including pseudo-closed SQL cursors).
v No other job has a lock on the table.
v The table does not have an active delete trigger.
v The table is not the parent in a referential constraint with a
CASCADE, SET NULL, or SET DEFAULT delete rule.
v The user issuing the DELETE statement has *OBJMGT or *OBJALTER
system authority on the table in addition to the DELETE privilege.

If any of the above are true, then the DB falls back to the originally
row-by-row delete.

HTH,
Charles

On Mon, Oct 29, 2012 at 1:42 PM, John McKee <jmmckee@xxxxxxxxxxxxxx> wrote:

Thanks Charles.

After I sent the email, I found the trigger program source. Looks
like all this one does is write add/chg/dlt to a log file. With that,
I thought the issues i had encountered with the SQL working but still
needing to touch things was also a trigger. Not in that case.

I would have thought that an SQL delete would not have worked, due to
the trigger. But, apparently it isn't an issue. Why doesn'r CPYF
MBROPTOPT(*REPLACE) fire the delete and add triggers? A reason not to
do so, would be a lot of additional overhead, therefore a performance
issue. Any other reason?

John McKee

On Mon, Oct 29, 2012 at 12:11 PM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

The delete trigger is causing the problem...

Tables with a delete trigger don't allow the CLRPFM that implict in a
CPYF MBROPT(*REPLACE)

I think it will work if you can disable the trigger..

Another option, simply use SQL
delete from testfile

insert into testfile select * from prodfile

However, in either case you should figure out what the triggers do.
Perhaps you need them to fire, perhaps you don't want them to fire in
this scenario. Only you can figure that out.

Charles

On Mon, Oct 29, 2012 at 12:28 PM, John McKee <jmmckee@xxxxxxxxxxxxxx> wrote:

I was attempting to copy a live data file to our test environment.
Process was intended to refresh the file so I could test the SQL
process to delete records later this week.

Well, first part is to save the test environment file. No issue.
Then, copy and replace records. Doesn't work.

File has three triggers on it. After insert, after update, and after delete.

I am assuming I could disable the triggers in the test environment and
then do the copy. Am I correct? And, on the live environment, would
I have to disable one or more triggers to use SQL to delete selected
rows?

Both questions are easily answered by me just doing this in the test
environment. My concern, though, is what might happen to the live
environment if I disable the triggers (all, or just one), do the SQL
delete. and reenable the triggers. I am concerned that I might
introduce an error that causes problems days later. While the system
is going away, a number of accounts will remain on the system to be
worked for some months. I don't want to trash something that will
cause bigger headaches.

I needed to change four fields in one data file. Tedious, as there
are five fields and fourty-eight records. I had "bright idea" - just
use an UPDATE. The contents were updated, sort of. But, when the
file is changed using the approved method, some other changes are
made. Bottom line was that the maintenance program had to be used to
finish the changes. At least that mess was easily fixed.

So, I would like to test the SQL on test environment, but need to
refresh the file. Can't because of the triggers. Will disable allow
CPYF to update the file? What of the triggers? No idea, at this
point, what they do.

Any suggestions?

John McKee
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.