ApexSQL Audit FAQ

Yes, ApexSQL Audit can capture both operation types. The DML operations category includes: Insert, Insert bulk, Writetext, Update, Merge, Updatetext, Delete, and Truncate table; The DDL operations category includes: CREATE, ALTER, DROP, Add signature, Enable/Disable trigger, Rename object, Revert/Update statistics

Yes. ApexSQL Audit currently achieves this by seamlesly integrating our own trigger based solution. This enables users to easily and quickly create DML triggers for any SQL Server database, to deploy and manage them and to access collected data any time, by using intuitive and readable reports that can be exported to common formats like .docx and .csv. We’re also building a new integrated native solution based on CLR triggers that will be available in the very next release.

No. Although you can leverage the captured SQL statements in certain scenarios (e.g. if you choose to audit DDL changes, you can recreate a dropped stored procedure by executing the captured CREATE statement, given that the stored procedure was executed after the auditing was set in place), ApexSQL Audit isn't a recovery tool. If you are interested in recovery, check out our ApexSQL Log or ApexSQL Recover

No. ApexSQL Audit is fully functional during the 14 day trial period. After the trial period is over, you need to purchase the license to continue using it

ApexSQL Audit captures and reports on all of the activities on your SQL instances, including access and changes made to sensitive data, SQL login, user and password changes, as well as any permission or security related activities. Furthermore, the captured information is stored in a central repository, designed to make obvious any attempts to tamper with the captured data

No. ApexSQL Audit central repository database is hosted only by the central SQL Server instance that is selected by user during the installation process. Application will not install anything on additional SQL Server instances added for auditing. ApexSQL Audit installs the ApexSQL Audit windows service on a machine which hosts the audited instance(s) that collects the auditing information

No. ApexSQL Audit uses SQL Server traces

No, it uses temporary files containing SQL Server traces for analysis and transfer between the audited and central ApexSQL Audit instance. These temporary files are deleted when captured information is successfully stored into the central repository database

Yes. ApexSQL Audit uses SQL Server traces, the same technology used by SQL Server Profiler. But, in addition, we added fault tolerance for a wide variety of scenarios, additional processing of captured data, parsing for referenced objects, automatic transfers and loading into centralized repository, tamper-evident data storage, etc.

ApexSQL Audit has minimal performance overhead, equivalent to running the default trace

Yes. The central repository database is designed in such a way to make evident any attempts to tamper with the captured data

Yes. ApexSQL Audit provides alerting for data and system events on specified SQL Server instances, with email notifications and the alert overview dashboard

Yes. You can build your own custom reports

Yes. Using an API call, data can now be exported to the reporting source of choice (i.e. Power BI)