November 8th, 2011· Added new audit trigger option "Blank is Equivalent to Null". When this option is enabled, zero-length (empty) character values are considered null for all purposes of auditing. See the help under Trigger Options for more information.
· Added a preferences dialog to permit customizing the database query timeout duration; default is 5 minutes.
· Fixed an error when connecting to a database with a user that is not a database owner: "Field 'GroupName' not found".
· Fixed an issue where in a specific circumstance trial version auditing in a database may not be updated using registered software.
· Fixed some documentation mistakes.
November 8th, 2011· Fixed an issue with row key filtering in Audit Log Viewer. Row key data with trailing spaces no longer requires the user to pad the value to filter against.
· Eliminated dependency on SQL Server's xp_msver extended stored procedure, which is not always available.
· Added Save and Copy buttons for validation error messages and warnings.
· Added option for UTC timestamps in the audit log.
· Fixed error "Parameter 3 is incorrect for this DBCC statement" when converting an existing populated AuditLog table from Default to Identity option in a SQL Server 2008 database.
· Fixed issue when importing an audit setup if the audit log was targeted to a second database, it would reset to the audited database when imported.
· Window panels did not always resize properly on 64-bit Windows
· Fixed problem when a user-defined data type was a text, ntext, or image type.
· Fixed a few minor visual issues with multiple monitors.
November 8th, 2011· Added support for SQL Server 2008 data types: DATE, TIME, DATETIME2, DATETIMEOFFSET, HIERARCHYID, GEOMETRY, and GEOGRAPHY.
November 8th, 2011· Under some conditions, the Build Log Tables screen would allow the user to change the audit log database after audit data was collected in the audit tables. This is not normally allowed, but was not being prevented and resulting in an error in some special circumstances.
· Custom user name tracking was not properly setup when the audit log used identity-generated ID numbers rather than default ID numbers.
· The stored procedures pr_kr_AuditSetStatus and pr_kr_AuditLogConnectionInfo now use SET NOCOUNT ON to prevent row count messages from returning.
· Using the custom user name stored procedure pr_kr_AuditSetUserName was not properly handling user names greater than 30 characters in length.
· Some options on the Build Log Tables screen were not properly enabled if auditing was uninstalled and then immediately reinstalled in a database.
November 8th, 2011· If the audited tables contain a field identifying the user responsible for an insert or update, you can now instruct OmniAudit to pull the username from that field and report it in the audit trail as the user responsible for that activity. See "Getting the User Name from the Audited Table" in the help.
· Each column in the Audit Setup grid can now be filtered by selecting a value from the dropdown list in the column header. For example, you can filter for all tables not selected for audit, all table belonging to the same owner, etc.
· Fixed a problem which under some circumstances would produce an "Incorrect syntax near '%'" error when building audit log tables or triggers.
· Fixed audit setup import which was not unselecting the "audit deletes" options in the target database if they were already selected in the existing database setup but not in the imported setup.
· Fixed improperly displayed BLOB values in OmniAudit Log Viewer. This was a bug introduced in the last release.
November 8th, 2011· In OmniAudit Log Viewer a bug was introduced in the last release and corrected here. In some cases the "Old Value" for updates was displaying as N/A instead of the actual value. The underlying data was correct, this was just a display issue.
· Corrected a problem when viewing triggers within OmniAudit Manager: the script viewer wasn't showing trigger code when the table was owned by a user other than dbo.
November 8th, 2011· When building audit triggers, there is now an option to preview the trigger script using SQL Management Studio if it is available. There is also an option to save the script to a text file for later use.
· When using the COM interface to script audit triggers, the Errors property is no longer used. Any errors will now raise exceptions.
· Fixed "database not found" error when trying to connect to a new SQL Server while already connected to a different one.
· The optional stored procedures pr_kr_AuditSetUserName and pr_kr_AuditSetStatus were not being created when audit log was in a different database than the one being audited.
· The optional stored procedure pr_kr_AuditLogConnectionInfo was not being dropped when auditing was uninstalled from a database.
· gdiplus.dll is now installed in the application folder for Windows NT and 2000. The application would not function when these older operating systems were not already upgraded with gdiplus.dll.
· The omniaudit_logwriter database role is now created in the audited database when the audit log tables are also in the same database. Previously this database role was only created when the audit log tables were in a separate database.
· OmniAudit Manager and OmniAudit Log Viewer will no longer start in a minimized window state. In prior versions, this could have occurred if the application was previously closed in a minimized window state.
· Resolved the error "Could not find a table or object named ''. Check sysobjects." which could occur when building triggers on tables not owned by dbo.
· In the AuditConfig table the name of the database containing the audit log is stored. This caused issues if the database was renamed as the actual database name would then differ from what was stored in AuditConfig. Now if this entry is blank it is assumed that the audit log tables are in the audited database. The database can then be renamed at will without causing any synchronization problems. However, when the audit log tables are in a separate database from the one being audited, the database name must still be provided in AuditConfig (and will still suffer from issues if the audit log database is ever renamed).
November 8th, 2011· OmniAudit Log Viewer: Performance was improved when returning results while all filter values are empty.
· General compatibility updates for Microsoft Windows Vista.
· OmniAudit Log Viewer: When using the Row Key filter with a table having more than one column as its row key, pressing ENTER now advances focus to the next key field. Pressing TAB advances focus to the next control in the dialog.
· When audit log configuration changes have been made in the Build Log Tables screen, the user is now reminded to rebuild the audit triggers when those changes invalidate any existing audit triggers.
· OmniAudit Log Viewer: the Transaction ID column has been renamed to Operation ID. This corresponds to AuditLogID in the audit log tables/views (and always has).
· When errors or warnings occur while installing audit triggers, the message frame is no longer locked to the bottom of the application window. It is now a resizable, free-floating dialog which remains visible even while making adjustments in the OmniAudit Manager settings.
· Fixed a problem which produced the error "Class TADOQuery not found" with an existing audit log setup when the Audit Log ID option was changed from Default to Identity.
· Fixed a problem which produced the error "Could not convert variant of type (Null) into type (Int64)" with an existing audit log setup when the Audit Log ID option was changed from Identity to Default.
· Fixed a possible foreign key violation on the AuditRelationships table when importing an audit setup.
· Fixed a problem which produced the error "Property value is invalid" when moving an existing audit log from a separate database back into the audited database.
· Documentation for scripting audit trigger generation incorrectly described the ActiveX program ID as "Krell". As of version 1.9, the ActiveX program ID is "krAudit19". Prior to this version the program ID is "krAudit15".
· OmniAudit Log Viewer: the Detail pane now correctly aligns with the right edge of the application window when the application is resized.
· OmniAudit Log Viewer: was incorrectly reporting for New Value on delete operations for text, ntext, or image field. Now correctly reports .
· Fixed a problem when modifying an existing relationship associated with an existing lookup. The lookup properties were being erased and had to be re-entered.
· Fixed several display issues when using Large Fonts or 120 DPI screen resolution.
· OmniAudit Log Viewer: when a text, ntext, or image field was null, it was reported as in the results grid. Now it reports as and the notation only refers to non-null values.
· When connecting to a SQL Server, port numbers up to 65535 are now allowed.
· Fixed a problem which caused a server timeout when removing all audit triggers from a database if there was a large number of audited tables. This problem could appear both when clicking "Remove All Audit Triggers" from the Build Triggers screen, or when using Uninstall Auditing. A timeout should no longer occur no matter how many tables are audited.
· Fixed a problem in the New Lookup dialog which was displaying values for an existing lookup (if one was available) rather than empty values.
· OmniAudit Log Viewer: fixed the filter picklists so that their contents refresh when switching to a different database.
· OmniAudit Log Viewer: fixed the Row Key filter to work correctly when the row key values had leading spaces.
· Fixed an assertion failure error when displaying the About Box while running the application under a restricted Windows user account.
· Fixed the display of trial version days remaining when the application is run under a restricted Windows user account.
· Corrected the "Select All Columns (to audit)" feature so that it no longer tries to audit computed columns in the table.
· Under Windows Vista, the MDAC version was being incorrectly detected and prevented the application from running.
· OmniAudit Log Viewer: Fixed the display of multiple key columns in the Row Key filter. Previously the columns were listed in alphabetical order, but stored in the audit log tables in physical order. Matches would fail if this order wasn't the same. Now the Row Key filter dialog displays the fields in physical order and assembles the query expression in the correct sequence to match the data as stored in the audit log tables.
· Fixed a problem storing license key information when the Windows user account has limited permissions to write to the Windows registry.
· The SQL Server system view dtproperties is no longer displayed in the Audit Setup page as a table available for auditing.
· Some controls were displaying incorrectly when Windows themes are not turned on (as in Windows XP) or available (as in Windows 2000).
· When there are a large number of audited tables and/or columns for a database, performance was hindered in some navigation operations within OmniAudit Manager. These issues have been reduced although not entirely eliminated.
· If user-defined triggers exist on an audited table, and one of those triggers is already marked to execute last, then an error would occur when installing audit triggers. Normally audit triggers are set to execute last and only one trigger can be so marked. Now the audit triggers are installed regardless and a warning is shown explaining that the audit trigger could not be marked to execute last.
· Fixed a problem when installing audit triggers after migrating a MSSQL 2000 database to a MSSQL 2005 server and leaving the database compatibility at 80 (2000). Installing triggers in the database would create incorrect data conversion capacities for audited values. Capacities are expanded in MSSQL 2005 but, in this case, the database is still defined with MSSQL 2000 capacities. This could have resulted in a "String or binary data would be truncated" error if the audited data actually exceeds the MSSQL 2000 limits.
· Fixed a problem causing the application to not properly read the license key information when running under a Windows user account with limited Windows registry permissions if the license key was originally registered in the application under a Windows user account with administrator permissions to the Windows registry.
· Fixed a problem in audit trigger generation for lookup return values which require an explicit data conversion. For example, money datatypes require an explicit conversion to character in MSSQL 7 and 2000 but not 2005.
November 8th, 2011· Fixed OmniAudit Log Viewer, the column filter picklist was not showing columns for the most-recently selected table.
· Fixed OmniAudit Log Viewer when opening a filter picklist the contents would show the previously used filter's pick list until the data was fully loaded and the picklist redisplayed.
· Fixed OmniAudit Log Viewer, the selected value from a picklist was being sent to the wrong filter edit control.
· Fixed OmniAudit Log Viewer loading a picklist could result in a query timeout error.
November 8th, 2011· When upgrading an existing audit database, the old pr_kr_AuditLogConnection stored procedure used for custom username auditing is now preserved and rewritten to be compatible with the new custom username architecture.
November 8th, 2011· Added direct support to temporarily disable auditing for special activity. Previously this was available upon request through a separate add-on module. See "Suspending Auditing Programmatically" in the OmniAudit Manager online help for more details.
· Added direct support for tracking custom usernames sharing a single SQL Server login account. Previously this was available upon request through a separate add-on module. See "Multiple Users Sharing a Single SQL Server Login Account" in the OmniAudit Manager online help for more details. Users previously using the separate add-on module to track custom usernames must make changes to adapt to the replacement for that module built-into this update. See the following URL http://support.krell-software.com/articles/omniaudit-username-tracking.asp
· When the audit log is kept in a database separate from the audited database, OmniAudit Manager now creates a new database role called omniaudit_logwriter. This role is assigned all the permissions needed by database users to properly execute the auditing objects. Your database users must be added to both the audited and audit log databases, and assigned to the omniaudit_logreader database role in the audit log database. Assigning special permissions to users is not necessary when the audit log tables are in the same database that is being audited.
· In OmniAudit Log Viewer, the default maximum audit log entries to return can now be specified as a user preference under File | Preferences.
· Added a row key lookup filter in OmniAudit Log Viewer so that audited activity for a specific row in a specific table can be isolated directly.
· The filter criteria controls in OmniAudit Log Viewer have been reworked such that the dropdown lists are now history lists of previously used values. A separate picklist button is now available to directly select actual values.
· Non-dbo users logging into OmniAudit Manager are no longer restricted to managing audit selections only for tables they own. They now can manage audit selections (choosing fields and tables to audit and updating the appropriate triggers) for tables owned by other users (such as dbo, for example). Non-dbo users must be added to the omniaudit_admin database role as well as the db_ddladmin database role.
· Fixed error "Incorrect syntax near 'ObjectOwnerNameFunc'" in OmniAudit Log Viewer when connecting to a SQL Server 7 database.
· The AuditHistory and AuditHistory2 views no longer use hardcoded references to the audited database name when they are in the same database that is being audited. The database name reference now only appears when the audit log tables are in a separate database.
· The AuditHistory2 view was not being removed when auditing was removed from the database.
· Fixed a problem where users who were not a database owner, but were members of the omniaudit_admin database role, were getting the error "User 'xyz' is not authorized to access the audit setup". This only happened when the database user name did not match the SQL Server login name.
Find us on Google+
