Change Data Capture or Change Tracking - Same as Traditional Audit Trail Table?

Question

Before I delve into the abyss of Microsoft documentation any deeper, I'd like to know if someone experienced with Change Data Capture and Change Tracking know if one or both of these can be used to replace the traditional ...

"Audit trail table copy of the 'real table' (all of the fields of the original table, plus date/time, user ID, and DML action field) inserted into by Triggers"

... setup for a database table audit trail, where the trigger populates the audit trail table (which is all manual work).

The MSDN overview documentation explains at a high level what Change Data Capture and Change Tracking are, but it isn't clear enough to me, and doesn't state outright, that these tools can be used to replace the traditional audit trail tables we've made so often.

Can someone with any experience using Change Data Capture and Change Tracking save me a lot of time, or confirm that I am spending time looking at the right tool? The critical part of our audit trail is capturing all changes to a table's fields (on INSERT, UPDATE, DELETE), when it happened, and who did it. These changes are commonly provided to an end user chronologically via an audit trail report. Which is another question ... Change Data Capture or Change Tracking is the solution, I'd assume that this data can be queried just like data from a normal table?

EDIT: I need a permanent audit trail, irregardless of time. I see that Change Data Capture has to do with the transaction logs, so this sounds finite to me.

Answer 1

I think you still need audit tables in your circumstances. Looking in BOL it appears that a cleanup job is automatically created and ascheduled that runs every day at 2 am. From BOL:

The cleanup job runs daily at 2 A.M. It retains change table entries for 4320 minutes or 3 days, removing a maximum of 5000 entries with a single delete statement.

That sounds like it definetely doesn't do what you want. I can't think that would do what anyone who audits tables woudl want. It also appears that it would be difficult if not impossible to add any fields not in the data table to the audit log other than it's own five default fields (I couldn't find what they were.) It also appears that the data would not be very useful to query or to use to rollback a specific bad change. OR maybe I just don;t understand the process because BOL is pretty poorly written on this subject, it certainly didn't answer any of the concerns I would have in replacing my auditing with this apparently poorly thought out process.