IDERA strives to ensure our products provide quality solutions for your SQL Server needs. The following known IDERA SQL Compliance Manager issues are described in this section. If you need further assistance with any issue, please contact .
To download the Report Viewer 2010 controls program follow link below:
When working on a secondary node of an Availability Group, use the secondary´s instance name. |
Use the file path to determine the traces related to SQL CM. Or check the Agent Properties for the audited instances to verify the trace directory file path. |
( Fixed in version 5.5.1 ) When users try to upgrade from SQL Compliance Manager 4.5 to 5.5, trace files are not processed. If you currently work with SQL Compliance Manager 4.5, before upgrading stop the Collection Service, Agent Service, and disable auditing to stop trace file processing, then proceed to upgrade to SQL Compliance Manager 5.5, and configure and enable auditing. Upon upgrading to SQL Compliance 5.5, users must upgrade all agents to a 5.x version first. For more information, see Upgrade to this build.
( Fixed in version 5.5.1 ) The SQL Compliance Manager Collection Server is not processing trace files, or processing them slowly, causing backlog files to get accumulated in the Collection Trace Directory in large transactional databases.
The workaround for this issue is to increase the tamper detection interval and the Collection interval.
( Fixed in version 5.5.1 ) IDERA SQL Compliance Manager installation fails if TLS 1.0 is disabled and if SQL Server 2012 Native Client is not available. IDERA SQL Compliance Manager 5.5 installs SQL Server 2012 native client (version 11.0.2100.60) which does not support TLS 1.2 enabled as per Microsoft.
https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server
Users with SQL Server versions prior to SQL Server 2012 R2 SP3 need to enable TLS 1.0 or update the native client to the supported version (11.4.7001.0) following the link below:
https://www.microsoft.com/en-us/download/details.aspx?id=50402
( Fixed in version 5.5.1 ) SQL Compliance Manager does not process trace files generated by an older Agent after upgrading versions of the Collection Server and the Agent.
( Fixed in version 5.5.1 ) When performing an archive of a highly transactional database with SQL Compliance Manager, the application shows a “violation of PRIMARY KEY constraint” error and terminates the statement. The workaround for this issue is to rename the current archive database, along with the database files associated to it and perform a new archive operation. The operation should create a new archive database and database files.
( Fixed in version 5.5 ) During an Agent-only installation, if you accept the default destination path for SQL Compliance Manager, and then select a different destination drive and use a sub-folder in the Agent Trace Directory dialog box, the installer does not create the Agent Trace Directory during installation. If this issue occurs, reinstall the Agent specifying a folder instead of a sub-folder as the destination path or use the default path specified in the installer.
The Audit Events tab may display an incorrect user name in the Login column when auditing start and stop server events.
( Fixed in version 5.4.2 ) A known SQL Server issue causes some SQL Compliance Manager SELECT statements to appear as DML events. This issue occurs when a user audits both SELECT and DML. SQL Compliance Manager captures many events when certain columns are selected from certain system tables from a single SELECT statement query and shows them as individual DML events.
Specifically, the SELECT statement which uses the permissions()
function generates only DML event traces and not a SELECT event trace. This step results in SQL Compliance Manager reporting the SELECT statement as a DML event. In addition, the permissions()
function is deprecated. Microsoft recommends in MSDN documentation that users implement the Has_Perms_By_Name()
function instead of the permissions()
function. The difference between these two functions is that the permissions()
function always generates the DML event traces while the Has_Perms_By_Name()
function generates event traces according to permission type used. For example, SELECT event traces for SELECT permission types, and DML event traces for EXECUTE or DELETE permission types.
( Fixed in version 5.4.2 ) Users who change the default port for the AlwaysOn Availability Group from the default may experience the following issues. to avoid these issues, change the listener to the default port.
When you change the definition of a table you are auditing to include BLOB data types, the Before-After data trigger prevents UPDATE, DELETE, and INSERT operations from modifying the table, such as through stored procedures or third-party applications. This issue is most likely to occur when you are auditing all columns in the target table. This issue occurs because Before-After auditing does not support BLOB data types (such as text, image data, or XML code). To correct this issue, change the data definition of the table.
SQL Compliance Manager does not support collecting and processing events from encrypted SQL Server trace files. This issue is most likely to occur in environments that use third-party encryption software. For example, some applications can be configured to automatically encrypt all new files created on a specific computer. If you are running encryption software in your SQL Server environment, verify the encryption settings to ensure the application does not encrypt trace files on the audited SQL Server instances.
| | | | | | | |