A: OmniAudit installs triggers on the tables you select to audit. Triggers are events that automatically execute every time a row in a given table is inserted, updated, or deleted.  OmniAudit's triggers are specially built to examine the columns you've selected to audit in that table to determine if the data in that column has been changed.

A: OmniAudit supports SQL Server 7.0, 2000, and 2005 including MSDE and SQL Server Express editions.

A: No. OmniAudit is completely installed on the database server and is transparent to all applications affecting the database.  This includes

• All standard database tools such as Enterprise Manager and Query Analyzer.
• All commercial applications such as Access and Excel.
• All web applications based on CGI, Perl, ASP, ActiveX, Cold Fusion, etc.
• All your existing proprietary applications.

A: OmniAudit captures information for each row that is inserted, updated, or deleted.  For each column that you selected to audit in that table, the before and after values^1,2 of the column are stored, as well as

• The username of the person who made the change.
• The date and time of the change.
• The name of the application that was used to make the change.
• The name of the computer the application was running on.

¹ Before-and-after values are only available for update operations.  For inserts, the value of the column at the time of the insert is stored.  For deletes, the value of the column at the time of the delete is stored.

² Due to how SQL Server handles BLOB data within triggers, before-and-after values are not available for text, ntext, or image columns.  In these cases, the value of the column after it was updated is all that is available and is all that OmniAudit posts to the audit log.

A: Audit log data is stored within tables created by OmniAudit.  These tables can be installed in the same database being audited or in a different database on the same server.  These tables are fully queryable via SQL or other data access tools.

We also provide a companion application OmniAudit Log Viewer which makes it easy for you to sift through audit log records. You can filter and sort the audit log by audited table and audited column as well as date and time, user, application, etc. OmniAudit Log Viewer is a great tool for QA and Tech Support staff.

A: As we mentioned, audit log data is stored within database tables.  Numeric types such as int, decimal, float, etc. are converted to character representation when written to the audit log.  The same is true for binary, varbinary, and uniqueidentifier types. BLOB types (text, ntext, and image) are stored in dedicated tables which preserve their type.

A: You have complete control over which tables are audited and which columns in those tables are audited.  In fact, you would be wise to carefully consider your audit plan, because the more you audit, the more space your audit log will occupy and the more activity your server will have to bear to perform the auditing.

A: No.  You can choose any combination of the insert, update, or delete operations, and you can change this selection table-by-table.  For example, some tables might audit all three operations while others may only audit update operations.

A: All datatypes are supported in all SQL Server versions.

A: Generally, it is simply a matter of running the Audit Manager, selecting the table that was changed, and clicking "Build Triggers" to recreate the triggers for that table.

A: Yes you can.  SQL Server permits multiple triggers to exist on the same table.  OmniAudit's triggers will happily co-exist on a table side-by-side with any triggers of your own.