=============
PROGRESS V8.3C
=============
Hi all,
Because of a rather quick expanding "internal" market for our application, the demand for better "data" security increases
each day. (internal competitors)
On the other hand because of a limited development & implementation time, we try to keep the original code intact
as much as possible.... maximum impact with minimum effort...
We solved this issue through the use of FIND triggers in which
we verify the authorization on each record....
If verified and okay....a normal "RETURN" is done, leading to a "visible" displayable record....
if verified and NOT okay, we block the access to the record by
performing a "RETURN ERROR"...and the record is skipped....
This solution works quite well.... however when the number of
"blocked" records increase, the performance of the trigger decreases rapidly, leading to increased, unacceptable user response times....
We traced the performance decrease back to the "RETURN ERROR" statement in the trigger.....the rest is performed as
quick as ever.
Does any know how to increase trigger performance, but keep
the "blocking" of the record intact..... we already tried NEXT ???
PROGRESS V8.3C
=============
Hi all,
Because of a rather quick expanding "internal" market for our application, the demand for better "data" security increases
each day. (internal competitors)
On the other hand because of a limited development & implementation time, we try to keep the original code intact
as much as possible.... maximum impact with minimum effort...
We solved this issue through the use of FIND triggers in which
we verify the authorization on each record....
If verified and okay....a normal "RETURN" is done, leading to a "visible" displayable record....
if verified and NOT okay, we block the access to the record by
performing a "RETURN ERROR"...and the record is skipped....
This solution works quite well.... however when the number of
"blocked" records increase, the performance of the trigger decreases rapidly, leading to increased, unacceptable user response times....
We traced the performance decrease back to the "RETURN ERROR" statement in the trigger.....the rest is performed as
quick as ever.
Does any know how to increase trigger performance, but keep
the "blocking" of the record intact..... we already tried NEXT ???