Question Define trigger for all tables

patelspam

New Member
Hi there!
I wanted to ask if there's a way to create a trigger for all tables ("write" for example).
I was thinking on using the following code in a persistant procedure:
Code:
ON WRITE OF Customer DO:
END.
But I don't want to have to have a block of code for each table. Is there a way to do the previous code dynamically? If not, what would be my best option?

Thank you!
JP
 

tamhas

ProgressTalk.com Sponsor
You might start by telling us why in the world you want to do such a thing.
 

patelspam

New Member
You might start by telling us why in the world you want to do such a thing.
The record i want to create in this trigger is a kind of log. Something that will alow to track everything a user does but only developers have access to it. For example: I update table A. The trigger "write" of table A will create record on table x, saving all information necessary to track and revert this activity any time i want. I don't want to export it or anything like that. It's just for interval/development usage). This would be added to more than 130 clients. I need a fast, simple and low-time-consuming solution... Doing it dynamically would be better than writing a block of code for each table (around 300 tables).
 

patelspam

New Member
So you want to re-invent auditing?
Hey Tom!
My plan is implementing this "system" in 130 clients. The way i tought would only require max 2 minutes per client (replace a file and recompile another). And if I ever wanted to add specific logging messages and do anything extra (that wasn't planned) or improve my logs it would be very fast to implement . I have the idea that using "audit" would require more time and effort to do something specific. I already saw 1 video about it and read several progress documents and it doesn't seem to be the best option (at least in my opinion). Do you mind telling me what was your idea, and what it would improve by comparing it to my (inexperienced) idea?
 

TomBascom

Curmudgeon
The big advantage of auditing is that it is built-in and reliable.

The big disadvantage of roll your own is that you have to find all of the edge cases and rough edges on your own. And those pesky users can tamper with your audit logs.

Generally speaking I am skeptical any time someone (including myself) says that something will require a max of 2 minutes. Those projects have a bad habit of turning into multi-month death marches.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
track everything a user does but only developers have access to it.
That's auditing.

Even if you take a long time to create your own audit-like system, you are still writing your audit trail to an application table. There is nothing you can do to protect the data in this table, in a customer database, that the customer can't circumvent.

OE Auditing includes runtime protection for audit tables, based on the audit roles that you assign. If you don't use it, you have no guarantee of the integrity of the audit trail and the exercise is pointless.
 
Top