Extended Events Collation resolution error

Question

When trying to expand the sessions under extended events I am getting a Collation Resolution error in SSMS 18.2 (15.0.18142):

Looking at a trace I have found that this query is what is giving me the collation error but I can't see why? All of the system DB's have the same collation

SELECT * FROM sys.server_event_sessions AS session
LEFT OUTER JOIN sys.dm_xe_sessions AS running ON running.name = session.name

Answer 1

This appears to be a conflict between the instance (i.e. server) -level collation and the collation being used in the [master] database. Both sys.server_event_sessions and sys.dm_xe_sessions are system catalog views, and the collation of their [name] fields should be the same.

sepupic had the O.P. execute the following:

select top 1 sql_variant_property(name, 'collation') from sys.server_event_sessions;
select top 1 sql_variant_property(name, 'collation') from sys.dm_xe_sessions;

The results were:

sys.server_event_sessions = Latin1_General_CI_AS
sys.dm_xe_sessions        = SQL_Latin1_General_CP1_CI_AS

That difference should not be possible, but at least it explains the error message.

I requested that the O.P. execute the following to determine the instance-level collation:

SELECT SERVERPROPERTY('collation');

O.P. replied with:

... the server collation is "SQL_Latin1_General_CP1_CI_AS". I was under the impression that the Server collation was whatever the master DB collation was. This server was installed from a Microsoft Azure image so the collation was changed from SQL_Latin1_General_CP1_CI_AS to Latin1_General_CI_AS.

Clearly something went wrong with the collation change process. I was able to reproduce the error by creating a database containing one table with one string column. I used a case-sensitive collation and that one column was also the Primary Key (meaning: a unique index). I added two rows: N'A' and N'a'. I then used the sqlservr.exe -q method (details linked below) of globally updating the collations to change the instance's collation to a different one, one that was case-insensitive. When the process tried to rebuild the PK, it failed as the case-insensitive collation rendered the second row not-unique from the first. But, the system DBs has already been updated. However, the instance level collation was not changed to the new collation as the process never completed.

To fix this, I believe the following would work:

1. Detach all User DBs (to minimize impact of the operation: the user DB's are not a problem, and some columns might have different collations set that shouldn't be changed)
2. Update the instance's collation using the sqlservr.exe -q method
3. Re-attach the User DB's