two reasons related to the vtDDLAudit database level trigger:
1) We are not capturing duplicate events due to the WHERE clause so if someone has ever disabled a table level trigger in the past then subsequent events will not be recorded
2) We are not capturing ANY trigger disable/enables if someone calls "disable trigger" or "enable trigger" from SSMS
Andrew Karr
| Company | EMCOR |
| Job Title / Role | IT Mgr |
| I need it... | Yesterday...Come on already |
Dear Viewpoint Suggestion Box contributor;
We at Viewpoint sincerely thank you for your contribution to Suggestion Box on how we can improve Viewpoint products. While we can’t do everything at once, we rely upon your feedback to help guide the prioritization of our product improvements, and Suggestion Box is a critical tool for us to understand and prioritize our customers’ needs.
Viewpoint reviews Suggestion Box regularly for all of our products and updates statuses, adds comments, and performs various house-keeping (including deleting) as needed to ensure that Suggestion Box is maintained as a productive environment for product enhancements requests.
Count my vote as well! https://www.sqlshack.com/various-techniques-to-audit-sql-server-databases/ lists the various strategies that can be used. If everyone were to upgrade to 2016+, I think CDC might be a good fit? https://www.sqlshack.com/change-data-capture-for-auditing-sql-server/
I agree that the entire audit should be reviewed. We had to use the audit recently to restore records that were modified since the last backup and it was painful because of how much isn't captured (and we have full auditing turned on).
I think it would be helpful if the entire auditing process would be re-visited in the system. An audit, fif you want to really provide one, should be able to identify who change what and when it happened. The current VP database auditing falls way short of that mark.