Summary
This article provides a list of SQL Server events for each operation type group used in ApexSQL Audit GUI (DDL, DML, Query, Execute, Error, Warning, and Security).

Description
The events audited by ApexSQL Audit are divided into 7 groups, by operation type.

ApexSQL Audit provides a range of built-in queries as part of the reporting module that cover the most common user reporting requirements. For more specific reporting requirements, we have provided a possibility to create custom SQL Server auditing reports by using a drag-and-drop technique. If this still doesn’t provide the specific information you need, you will still be able create queries and reports of your own using T-SQL , due to the fact that ApexSQL Audit stores all audited data in a SQL Server database.

ApexSQL Audit stores all configuration and audited data, from local and remote SQL Server instances in a centralized repository database named ApexSQLCrd. The packages with captured data are transferred automatically and safely via network, parsed, and data is stored into the central repository database. This approach makes it is easier to backup and protect captured data.

Summary
This article describes the limitations you should consider when working with ApexSQL Audit.

Description
The maximum number of audited distributed instances
There is no specific limit on the number of auditing instances (remote SQL Servers) that may be audited. The maximum number depends on your environment, the number of transactions executed against audited servers/databases and network bandwidth. The more distributed instances, the more likely it may be for you to encounter performance problems, as a large number of packages transferred through your network can cause bottlenecks.