Re: SQL and trigger s

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.