Performance increase for FIND trigger

[Fredmeu]

=============
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 ???

 

[ChrisPaulson]

Sounds to me you are going about this the wrong way. To block records you dont want you should be filtering them out with the where clause in your query, hence letting the DB do the hard work.

By doing it with a find trigger you are getting back all records but throwing them away - very wasteful.

Not only that but find triggers are a nightmare, you get them firing when you dont want them eg. when another screen uses the same table.

If you cant build the query in the way you want you could change the program to use a temp table and then build the temp table with the records you require.

 

[Fredmeu]

Hi Chris,

Of course you're absolutely right when telling me to use
query-clauses to define my desired record-set instead of
a find trigger..... its indeed an ugly type of programming we
use....

However using query clauses would mean a modification
of ALL programs using these tables, which would take
too much time to be realized in short term....

You also mention the firing of the find trigger as a disaster...
however for security reasons it would be a big advantage to
have them firing everywhere....this disables any possibility for
user-defined "backdoors".....

I however hope you or someone else can still help me improve
the performance of this ugly piece of trigger code...

 

[MSilva]

Well, here goes my 1 cent...

Your trigger is define as a Database trigger or a Application trigger??

Have you tried both??

Using Application triggers you'll change only programs directly associated with security...

It seems a half way solution ... Not Hell not Heaven

 

[Fredmeu]

Hi Msilva,

We make use of DB triggers, since application triggers would mean modifying all sources as well... maybe your suggestion
of only modifying the toplevel entry-programs can be used indeed, but does leave user-defined "backdoors" open....

In any case thanks for the reply ... :awink: