Hi,
On 8/12/2016 18:39, mach...@seworx.co.za wrote:
...
So to recap what has been done for now :
- Triggers to insert a record in audit table to show
the table, type of query(insert/update) and who made the relevant change.
- Trigger to prevent deletes
Hi Guys
Thank you very much for all the input, I appreciate it.
@ Johan
Once again glad to deal with you. I do agree that triggers are
not the way to go and I personally also do not like using it unless
absolutely required.
I do feel other solutions may be better, however , un
Triggers are not the best way to go about this. Consider:
* What is to stop a malicious user from truncating the audit table?
* Triggers may fail (corrupt target table, for instance) and a trigger failure
may cancel the source statement
* Triggers have a performance impact - you're basically
2016/12/07 01:26 ... mach...@seworx.co.za:
well in essence the following is required.
we need to know who made what changes to tables.
There is a machination that you can try in every trigger that will add
the user-name to the binary log:
set @asdfasdfasd = CURRENT_USER();
INSERT INTO