Re: Read triggers and SQL CQE or SQE

I'd suggest looking at the

exec SQL SET OPTION ALWCPYDATA = *NO;

That will force the DB to use the live tables without making a temporary
copy.

I'd also consider opening a PMR with IBM. It would seem to me that there
should be a difference between the DBMS "reading" a row to build a
temporary copy and actually returning that row to the application to be
used.

I've not used read triggers, but I'd assume that they don't fire for every
row when the system does a full table scan to find the rows to return.
They only fire for the rows being returned. That being the case, they
should fire when the system build a temporary copy for it's own use either.

Charles

On Wed, Dec 3, 2014 at 7:22 PM, Peter Connell <Peter.Connell@xxxxxxxxxx>
wrote:

Hi,
We have a read trigger based audit system to record who, when and why
certain files were accessed because of legal requirements.
It has been running for many years but is now causing issues with jobs
that process a large number of transactions using embedded SQL where each
transaction may launch several nested SQL requests that read files that
have a read trigger attached.

The problem appears to be that SQL decides not to use the more efficient
SQE method in favour or CQE which does things like creating a copy for a
table scan. This is making some jobs horrendously slow.
Redesigning the audit system to not use read triggers is beyond
consideration. Unless there is some workaround that can force the use of
SQE then we are faced with rewriting the SQL function points as native RPG
where they access files that have read triggers.

Does anyone have any suggestions.

Peter


#####################################################################################

This correspondence is for the named person's use only. It may
contain confidential or legally privileged information, or both.
No confidentiality or privilege is waived or lost by any
mistransmission. If you receive this correspondence in error,
please immediately delete it from your system and notify the sender.
You must not disclose, copy or rely on any part of this correspondence
if you are not the intended recipient. Any views expressed in this
message are those of the individual sender, except where the sender
expressly, and with authority, states them to be the views of
Veda. If you need assistance, please contact Veda :-
Australia http://www.veda.com.au/contact-us or New Zealand +64 9 367 6200
--
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.