This post is part of the series on Implementing Fastpath's Audit Trail and is part of the parent Implementing Fastpath's Assure Suite series.
Audit Trails tracks changes by creating triggers on SQL Server. When you create the triggers you do so by selecting a table, choosing the events to track and which fields to be audited:
You can separately choose to track inserts, updates and deletes by marking the relevant boxes, although in most cases you would want to track all three.
Next you can select any of the fields on the table for auditing; I’d recommend against tracking everything as this can make the audit data very large and if there are fields you don’t populate or aren’t important, then there is no point auditing them.
Likewise, you can audit as many tables as you want, but I’d recommend against auditing all tables as this can have an impact on performance. I’d also recommend against auditing transaction tables due to the volume of data which would pass through them.
In the next post, I’ll show how to apply the triggers for the selected tables and fields.
Implementing Fastpath's Audit Trail
Implementing Fastpath's Assure Suite
What should we write about next?
If there is a topic which fits the typical ones of this site, which you would like to see me write about, please use the form, below, to submit your idea.
2 thoughts on “Implementing Fastpath’s Audit Trail: Select tables to audit”