Question Make a trigger for read

[fdantas]

Hi friends,

is possible create a trigger for see when someone try read one information on database ?

 

[TomBascom]

Yes.

 

[fdantas]

Thanks Tom
how i do ?

 

[TomBascom]

Create a FIND trigger.

 

[fdantas]

i will try, very thanks

 

[RealHeavyDude]

You should be aware that FIND triggers will considerably slow down your application on tables where you implement them. Plus, they will only fire when these tables are accessed via the ABL - not when accessed via SQL.

Heavy Regards, RealHeavyDude.

 

[fdantas]

Very Cool. Thanks friend

 

[fdantas]

are possible i change the value of a field in this trigger ?

 

[RealHeavyDude]

Yes, it is possible. You can put any code into a trigger procedure that you can put in any other procedure.

But - I would not recommend you to do so. Usually one tries to get the best read performance out of an application. You do so by avoiding as much i/o on the database as possible and and have the operations as atomic as possible. If you update something in a FIND trigger, you are not even bouncing back and forth between the database engine and the ABL execution layer ( triggers are executed in the ABL execution layer in the client context and _NOT_ in the database engine ) for each record you retrieve for such a table, additonally you modify buffers in the shared memory which need to be written back to disk plus all the transaction overhead that the server does to make sure your data does not get corrupted.

Again, you can do that, but from a performance perspective this IS THE WORST CASE SCENARIO that one can think of when it comes to read performance. If you really must implement auditing on retrieval of record from certain tables you should look into the auditing functionality that is built into the database engine since OpenEdge 10.1A. This is because it is optimized to get the best possible peformance. And, as a bonus, you don't need to change any code in your application.

Heavy Regards, RealHeavyDude.

 

[fdantas]

In my case, i have one table with salary of all employees, and some have access a progress editor, and i like monitoring this field of table or block this field.
how do i use auditing functionality ? you have a documentation ? regards and very thanks for your help friend

 

[Rob Fitzpatrick]

In my case, i have one table with salary of all employees, and some have access a progress editor, and i like monitoring this field of table or block this field.
how do i use auditing functionality ? you have a documentation ? regards and very thanks for your help friend

If this is sensitive data that some or all users shouldn't access at all then instead of auditing after the fact who accessed the table, you could use the can-* permissions on the table's _File record to restrict access.

 

[fdantas]

If this is sensitive data that some or all users shouldn't access at all then instead of auditing after the fact who accessed the table, you could use the can-* permissions on the table's _File record to restrict access.

Cool, but how i do this Rob ? Exists documentation for this ? this protection change CRC of table ? I dont have source code of the system that my client use

 

[Rob Fitzpatrick]

Cool, but how i do this Rob ? Exists documentation for this ? this protection change CRC of table ? I dont have source code of the system that my client use

Read the documentation for your version (which you didn't mention). In the 10.2B documentation it's in the Managing ABL Applications manual, Chapter 3: Maintaining Application Security.

http://communities.progress.com/pcom/docs/DOC-103525

 

[TomBascom]

In my case, i have one table with salary of all employees, and some have access a progress editor, and i like monitoring this field of table or block this field.
how do i use auditing functionality ? you have a documentation ? regards and very thanks for your help friend

Just an observation that applies to a great many threads...

Starting off with a question about a specific technical issue and waiting until post #10 top describe your actual requirements is not a recipe for efficient problem solving. On the bright side you have now described those requirements. Some posters never get around to that.

 

[TomBascom]

Auditing does not directly support auditing of READ events. To do so would be extremely expensive from a performance perspective. (That doesn't stop people from asking for it though.)

There is a way to add user-specified audit events in your code. In theory, those could be tied to a FIND trigger. It would still be a dangerous thing to do from a performance perspective.

To BLOCK access to a table or field you should use the CAN-* permissions as Rob mentions.

 

[fdantas]

Just an observation that applies to a great many threads...

Starting off with a question about a specific technical issue and waiting until post #10 top describe your actual requirements is not a recipe for efficient problem solving. On the bright side you have described those requirements. Some posters never get around to that.

Sorry for this

 

[fdantas]

My version is 10.2B, i will read documentation, very thanks friends

 

[TomBascom]

Sorry for this

It's ok -- you're hardly the first. I just thought it was a "learning opportunity" as the thread morphed from one line of inquiry to another. With any luck at least a few people will notice that you get a much better answer when you provide better information.