Re: audit trails

2016-12-07 Thread Jesper Wisborg Krogh
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

Re: audit trails

2016-12-07 Thread machiel
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 ,

Re: audit trails

2016-12-07 Thread Johan De Meersman
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

Re: audit trails

2016-12-07 Thread Hal.sz S.ndor
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