I'm trying to tweak the "Server Activity" Data Collection set as outlined in this blog post (I wrote the post, btw. Sorry–it's kinda long). It is working in SQL 2008 R2 and also in SQL 2014. However, when I run msdb.dbo.sp_syscollector_update_collection_item
on SQL 2012, I get this error:
Msg 14696, Level 16, State 1, Procedure
sp_syscollector_update_collection_item, Line 70 Cannot update or
delete a system collection set, or add new collection items to it.
Looking at the code of msdb.dbo.sp_syscollector_update_collection_item
, I see differences between the SQL versions:
SQL 2008 R2/SQL 2014
IF (@is_system = 1 AND (@new_name IS NOT NULL))
BEGIN
-- cannot update, delete, or add new collection items to a system collection set
RAISERROR(14696, -1, -1);
RETURN (1)
END
SQL 2012
IF (@is_system = 1 AND (@new_name IS NOT NULL OR @parameters IS NOT NULL))
BEGIN
-- cannot update, delete, or add new collection items to a system collection set
RAISERROR(14696, -1, -1);
RETURN (1)
END
I'm passing in a non-NULL value for @parameters
, so I fully understand why I'm getting the error on SQL 2012.
Questions:
- Why is the code different for SQL 2012?
- Is it safe to manually change the code for
msdb.dbo.sp_syscollector_update_collection_item
?
Update: (version numbers for further clarification)
Ver SP Build Number
--------------------------
2008 R2 SP3 10.50.6000.34
2012 SP2 11.0.5058.0
2014 SP1 12.0.4100.1
Update2:
I've updated SQL 2012 to SP3 (11.0.6020.0)
The issue persists.
Best Answer
I think it's safe to say the
or @parameters IS NOT NULL
in SQL Server 2012 is a bug.Furthermore, the code prevents
sp_syscollector_validate_xml
from being called for non-system collection sets.Since the stored procedure appears to be a system-stored-procedure, you'll likely need to use
sp_MS_marksystemobject
to mark the stored procedure as a system-stored-procedure after you modify it to remove theor @parameters IS NOT NULL
code.Be aware that changing procedures that have been shipped by Microsoft may make support more difficult. I would recommend against making this change on production-critical instances.
For reference, the code as seen in my SQL Server 2012 instance is:
The code in SQL Server 2016 is: