If you ever did anything in SQL worth embedding into transaction(s), you were bound to encounter an age old problem of auditing failures in audit table(s) while at the same time rolling back the failed transaction. Problem ofcourse being that transaction rollbacks are efficient and blind in their duty and will leave no stone unturned while wiping out all evidence that your statements were ever executed on that server, this unfortunately including the inserts in the audit table. Kind of a catch 22 situation. Or was that the "chicken and the egg" dillema?

More...

There was an interesting topic in the [ES] forum that I moderate (serbian); to put it bluntly the guy wanted to use new SQL Server 2008 auditing functionality to check who of his users is "peeking" inside audit logs themselves ;), you know, the usual "who oversees the overseer" fallout. Just for a second we'll pretend that the would-be overseer wont copy the audit logs to his own instance of the SQL server ;) and that somehow he or she is forced to use SQL server to do it. Since one has to use fn_get_audit_file to parse the binary representation of the audit log into a meaningful table-to-query, we naturally assumed we could hook EXECUTE on master.sys.fn_get_audit_file function and this will solve the problem, you read the files => you get noted.

More...