|
|
 release notes
- Some options on the Build Log Tables screen were not properly enabled if auditing was uninstalled and then immediately reinstalled in a database.
- Using the custom user name stored procedure pr_kr_AuditSetUserName was not properly handling user names greater than 30 characters in length.
- The stored procedures pr_kr_AuditSetStatus and pr_kr_AuditLogConnectionInfo now use SET NOCOUNT ON to prevent row count messages from returning.
- Custom user name tracking was not properly setup when the audit log used identity-generated ID numbers rather than default ID numbers.
- 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.
- 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.
- 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.
- Fixed improperly displayed BLOB values in OmniAudit Log Viewer. This was a bug introduced in the last release.
- 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 a problem which under some circumstances would produce an "Incorrect syntax near '%'" error when building audit log tables or triggers.
- 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.
- 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.
- When using the COM interface to script audit triggers, the Errors property is no longer used. Any errors will now raise exceptions.
- 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.
- 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).
- Resolved the error "Could not find a table or object named '<trigger name>'. Check sysobjects." which could occur when building triggers on tables not owned by dbo.
- 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.
- 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.
- 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 optional stored procedure pr_kr_AuditLogConnectionInfo was not being dropped when auditing was uninstalled from a database.
- 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.
- Fixed "database not found" error when trying to connect to a new SQL Server while already connected to a different one.
- General compatibility updates for Microsoft Windows Vista.
- OmniAudit Log Viewer: Performance was improved when returning results while all filter values are empty.
- 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.
- 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 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: 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.
- 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.
- 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 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.
- 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.
- 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.
- Some controls were displaying incorrectly when Windows themes are not turned on (as in Windows XP) or available (as in Windows 2000).
- The SQL Server system view dtproperties is no longer displayed in the Audit Setup page as a table available for auditing.
- Fixed a problem storing license key information when the Windows user account has limited permissions to write to the Windows registry.
- 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.
- Under Windows Vista, the MDAC version was being incorrectly detected and prevented the application from running.
- Corrected the "Select All Columns (to audit)" feature so that it no longer tries to audit computed columns in the table.
- Fixed the display of trial version days remaining when the application is run under a restricted Windows user account.
- Fixed an assertion failure error when displaying the About Box while running the application under a restricted Windows user account.
- OmniAudit Log Viewer: fixed the Row Key filter to work correctly when the row key values had leading spaces.
- OmniAudit Log Viewer: fixed the filter picklists so that their contents refresh when switching to a different database.
- Fixed a problem in the New Lookup dialog which was displaying values for an existing lookup (if one was available) rather than empty values.
- 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.
- When connecting to a SQL Server, port numbers up to 65535 are now allowed.
- OmniAudit Log Viewer: when a text, ntext, or image field was null, it was reported as <see detail> in the results grid. Now it reports as <null> and the <see detail> notation only refers to non-null values.
- Fixed several display issues when using Large Fonts or 120 DPI screen resolution.
- 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.
- OmniAudit Log Viewer: was incorrectly reporting <see detail> for New Value on delete operations for text, ntext, or image field. Now correctly reports <N/A>.
- OmniAudit Log Viewer: the Detail pane now correctly aligns with the right edge of the application window when the application is resized.
- 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".
- 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.
- Fixed a possible foreign key violation on the AuditRelationships table when importing an audit setup.
- 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 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 OmniAudit Log Viewer loading a picklist could result in a query timeout error.
- Fixed OmniAudit Log Viewer, the selected value from a picklist was being sent to the wrong filter edit control.
- 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 column filter picklist was not showing columns for the most-recently selected table.
- 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.
- 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.
- 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.
- 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.
- In OmniAudit Log Viewer, the default maximum audit log entries to return can now be specified as a user preference under File | Preferences.
- 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.
- 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
- 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.
- 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.
- The AuditHistory2 view was not being removed when auditing was removed from the 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.
- Fixed error "Incorrect syntax near 'ObjectOwnerNameFunc'" in OmniAudit Log Viewer when connecting to a SQL Server 7 database.
- Fixed OmniAudit Log Viewer to be backwards compatible with older audit log tables.
- Added option when building triggers to optionally include/exclude the trigger body comment which identifies the user, date, time, and workstation from which the trigger was generated.
- Log Viewer would get error "Type mismatch for field 'NewValue', expecting: String actual: Memo" using SQL Server 2005.
- Duplicate column values were written in in AuditLogDetail.RowKey when auditing same-named tables with different owners.
- "Drop All Audit Triggers" only drops one set of triggers when auditing same-named tables with different owners.
- SQL Server 2005 now supported.
- Additional columns have been added to the AuditHistory view; each is a boolean value of either 0 or 1:
ValueIsText
ValueIsNText
ValueIsImage
ValueIsCapture
ValueIsLookup
- Computed columns can no longer be selected for audit.
- OmniAudit Log Viewer returned results are no longer limited to a maximum of 20,000 rows. Entering 0 for "max entries to return" will return all rows matching the filter criteria.
- When defining lookups for a table, if multiple relationships existed for the table, the "Return Column" dropdown list was only showing the columns available for the first relationship, regardless of the currently selected relationship.
- When a bit column is part of a table's unique key, building audit triggers no longer raises the error "Invalid operator for data type. Operator equals add, type equals bit."
- An entire database now can be selected for auditing with one button click: all tables and all fields within those tables will be selected for auditing.
- OmniAudit Manager did not always correctly identify database owner users and blocked certain operations.
- Table names containing a single quote character no longer cause an error creating or dropping audit triggers.
- Databases containing a very large number of total columns across all tables (many tens of thousands) or total indexes across all tables no longer cause a query timeout error when selecting the database for auditing.
- Corrected the bug which could cause the error 'Node "rules" not found' when importing an audit setup.
- Import/Export audit setup to copy audit configuration between two identical databases.
- The "return column" would not be displayed when editing an existing lookup.
- The "Write Float Keys as Whole Numbers" option now also applies to audited foreign keys.
- Using column names which are reserved words in the unique key no longer causes syntax error when generating triggers.
- When exporting in Log Viewer, an extra dot was being added in the filename extension. This also caused the file not to open automatically at the end of the export.
- When a unique key column is audited and the key value itself changes, the audit entry showed only the old key value and not the new key value.
- When changing the audit log ID representation between a serial number (default) and
an identity or vice-versa, converting existing audit log data has been optimized.
This significantly improves performance as audit log data is transformed from one
format to the other.
- When selecting the "Build Log Tables" page, there is a test to determine if there
is existing audit log data. This test has been made much more efficient and should
eliminate any delay that might occur when there is a very large number of existing
audit log records.
- In OmniAudit Log Viewer, when selecting an audit log database which is separate from
the audited database, an erroneous "OmniAudit setup not found" error was shown. This
was a problem introduced in build 1.6.4.278 and should not impact any builds prior
to that.
- In the Build Triggers task, there is a new option to treat all float fields in the
database as though they were money datatypes when converting their values to character
for the audit log. This avoids scientific notation when customers use float fields
to store currency values.
- When defining a relationship for a lookup field, if the name of the joining field
in the two tables are not the same, then their positions were being reversed when
constructing the join SQL. This resulted in an "invalid column XXX for table YYY."
generate when creating the audit triggers.
- When only nonaudited fields have changed in a row, an orphan AuditLog header records
was being created anyway. This was due to a problem introduced in v1.6. Versions
prior to that worked correctly.
- Add/Remove Program Files support info shows incorrect revision number
- Help | Contents menu item was always disabled
- Sorting on the date/time column now uses a date/time sort instead of a text-based
sort.
- Fixed problem introduced in previous build where audit triggers would fail with a
syntax error converting the PK value of some tables.
- Restored "Any" option for the column filter inadvertantly removed in the previous
build.
- Fixed problem where connecting to a server twice in a row caused an access violation.
- Added additional flexibility when creating the audit log tables. You can now choose how the AuditLogID identifier is created when audit records are added to the audit log database. The AuditLogID identifier can be either a generated value (the method used in previous versions), an identity, or a GUID. Depending on how you use OmniAudit, one format may be more efficient than another.
- When float values are used for a table's unique key, you have the option of storing the key value in the audit log as a whole number. This prevents the value from getting transformed into scientific notation by SQL Server when stored in the audit log.
- User interface controls are now fully compliant with Windows XP themes.
- When float fields are used in a table's unique key, the float value was being truncated to 6 significant digits.
- Field names and index names containing spaces were not properly handled in the Unique Key section.
- Minor improvements in exporting: 1 )Now warns before overwriting an existing file, 2) now remembers the last folder used, 3) now remembers the last export file type used, 4) after exporting, now gives the user the option to open the exported file
- When grouping data in the results grid, the context menu now has "Expand All Groups" and "Collapse All Groups" items.
- When multiple columns are needed to form the join relationship for a lookup, the triggers where creating a join expression which only used the last column pair.
- Generated triggers were not accounting for changes in a table's primary key or unique index when used as the tracking key for auditing purposes. If the composition of the primary key or unique index changes, then OmniAudit continued to generate triggers using the original columns.
- Problem exporting grouped data to Excel when the "Type" column is included. The "Type" column and the column prior to it were appearing blank in the export data. This only occurred if data was grouped and only when exporting to Excel.
- OmniAudit Manager 1.5.9 contained a faulty installer
- When running on Windows Server 2003, OmniAudit Manager was incorrectly reporting that the MDAC version was not at least 2.6. This was a warning only which could be skipped and OmniAudit Manager would continue unaffected.
- When running on Windows Server 2003, OmniAudit Log Viewer was incorrectly reporting that the MDAC version was not at least 2.6. This was a warning only which could be skipped and OmniAudit Log Viewer would continue unaffected.
- Corrected error "Property value is invalid" when connecting to some database servers after updates made to MDAC in Windows 2000 SP 3. The error occurred with database names which required bracketing (for example, containing a space in the name). Previous MDAC versions handled this automatically.
- Corrected error "Property value is invalid" when connecting to some database servers after updates made to MDAC in Windows 2000 SP 3. The error occurred with database names which required bracketing (for example, containing a space in the name). Previous MDAC versions handled this automatically.
- For SQL Server 2000, triggers are now created with trigger order set to "last" so that audit triggers fire after all other triggers on the same table.
- Added "Preferences" dialog under the File menu. Preferences lets the user set the query timeout value.
- Triggers produced the error "Cannot insert null value into AuditLogDetail.RowKey" when a value in the unique key of the table changes in the same update operation that changes another non-key column in the row.
- When generating triggers across different table owners using the "All Owners" selection, user would always get the error "No tables have been selected for auditing".
- Getting errors "SQL Server does not exist" at the build trigger point when a port number is used to identify the server. This also happens when the SQL Server has been improperly renamed in the past and @@servername does not reflect the correct name of the server. Both issues are resolved. Note: the 1.5.5 fix for @@servername dealt with the case when @@servername was null; the 1.5.7 fix deals with the case when @@servername is non-null, but is different than the actual servername.
- In databases with a large number of tables, regardless of how many tables were being audited, the "Build Triggers" process was taking a considerably long time to complete. The time to build triggers has been reduced substantially.
- When filtering by dates, the format of the date string used in the query is now determined by the SQL Server rather than the workstation.
- Display settings such as window size, grid column placement and width, and so forth, are now saved between sessions.
- Table and column names were incorrectly being truncated at 30 characters. Now handles object names up to 128 characters.
- When the SQL Server returned null for @@servername, would get "cannot connect to SQL Server" error when building triggers.
- Table and column names were incorrectly being truncated at 30 characters. Now handles object names up to 128 characters.
- Triggers now correctly handle user-defined datatypes.
- After registering an evaluation edition, user would get the error "Invalid object AuditLogDetail" upon entering a database which was setup with the evaluation edition, but audit log tables were never built.
- Triggers now correctly handle user-defined datatypes.
- After registering an evaluation edition, user would get the error "Invalid object AuditLogDetail" upon entering a database which was setup with the evaluation edition, but audit log tables were never built.
- Support has been added for auditing sql_variant datatypes.
- Lookups can now refer to views as well as tables.
- When creating a column lookup, the lookup name now defaults to the name of the column from the lookup table/view.
- Trigger script display now includes "Find Next", "Goto Line", "Select All", and "Copy to Clipboard" functions. Also displays script line numbers (convenient when backtracking trigger execution errors).
- No longer prevents execution if MDAC is less than 2.6; provides warning and allows program to continue. However, MDAC 2.6 is still the minimum supported environment.
- In Audit Setup, cosmetic changes were made to the User-Defined Unique Key definition dialog.
- When a key column is marked for capture, it wasn't being captured by the triggers.
- When auditing decimal/numeric columns with precision greater than 27, the triggers were not allowing enough characters in the conversion to character data for posting in the AuditLogDetail table. The triggers would produce an "arithmetic overflow" error.
- When returning lookup column values, a CONVERT was not being done in the triggers for datatypes requiring explicit conversion.
- When large character columns exceeding the capacity of the AuditLogDetail table are audited, the triggers weren't explicitly truncating the data during conversion; resulting in a "String or binary data would be truncated" error if the application warning level was set on the SQL Server.
- Key column names which require bracketing [ ] where not handled correctly and produced a syntax error when generating triggers.
- Cascading delete trigger on AuditLogDetail did not account for new Status value (introduced in 1.5) for data stored in AuditLogNText.
- Setting up merge replication was creating a "row size is larger than the maximum allowed rowsize" because merge replication was adding a rowguid column to the table.
- Modifying an existing lookup relationship gave "List index out of bounds" error.
- When using the "Single Table" option to build triggers, user got the error "you have not selected any columns to audit error" even after having gone back and selected some columns. This did not occur when the "All Tables" option was used to build triggers.
- When defining a table's unique key to have multiple key columns, save the audit setup, then remove one or more of the key columns in the audit setup for that table, the old key columns were not being taken off the key column list.
- The red/yellow flags for audited versus captured data was displayed in reverse (yellow for audited, red for captured; should be the other way around). This bug was introduced in version 1.5.2.
- When BLOB data was marked both for audit and capture, the BLOB data was not being captured when it is not changed (and some other audited column was changed).
- With merge replication, AuditLogAutoKeys table produced the error "failed because the row size would be 8076, including internal overhead". Reduced the size of the Filler column to accomodate the rowguid required by merge replication. This has no effect on any auditing functions.
- NText datatypes were not displayed correctly due to a change introduced in 1.5.
- When NOT FOR REPLICATION was unchecked when building triggers, it still appeared in the generated triggers.
- When setting up an audit log purge job, the job script contained an error which resulted in "Line 1: Incorrect syntax near 'month'." when the job executed.
|
