sp_BlitzLock Incorrect databasename for Check ID 9 if the database has a dot in the name

[Filip]

Version of the script
2.96
2020-06-06 00:00:00.000

What is the current behavior?
If the database name has a DOT in the name eg [Data.Base], only the last part of the name is returned in the database_name.

If the current behavior is a bug, please provide the steps to reproduce.
On [Data.Base] with Deadlock data, run:
EXEC [dbo].sp_BlitzLock @databasename='Data.Base'
result:

check_id	database_name	object_name	finding_group	finding
9	Base dbo.table More Info - Table	EXEC sp_BlitzIndex @DatabaseName = 'Base', @SchemaName = 'dbo', @TableName = 'table';

What is the expected behavior?
I expect the full database name.

Which versions of SQL Server and which OS are affected by this issue? Did this work in previous versions of our procedures?
Tested on 14.0.1000.169

[Filip]

Don't really know how to fix this, the real problem exists in the Deadlock XML report:
event name / data / value / deadlock / resource-list / keylock > objectname="Data.Base.dbo.table"
Seems to be missing the brackets [ ] around the different parts, and PARSENAME can't know that.

You could replace:
PARSENAME(dow.object_name, 3) AS database_name,
with:
DB_NAME(dow.database_id) AS database_name,

That fixes the database name.
But what if the DOT is in the tablename?

[Brent Ozar]

Yeah, I'd rather not do a halfway fix. If you come up with an all-the-way fix that works for all kinds of object names, definitely give that a shot, but for now I've added it to the documentation as a known issue, and closing it.

[Filip]

Agreed.

[Filip]

It can be done with the associatedObjectId attribute in the same keylock element of the report and a subquery:

SELECT s.name as schema_name, t.name
    FROM sys.partitions p
	LEFT join sys.indexes i ON i.object_id = p.object_id and i.index_id = p.index_id
	LEFT join sys.tables t ON t.object_id = p.object_id 
	LEFT join sys.schemas s ON s.schema_id = t.schema_id
    WHERE partition_id = >>associatedObjectId <<

But that's a big change.

[Filip]

@BrentOzar Could you reconsider re-opening this one?

[Brent Ozar]

Yeah, absolutely! Sorry about the delay on that - I saw the pull request on my phone and I made a mental note to come back here and reopen it, and it slipped my mind. Thanks for the reminder! I haven't looked at the code yet, but will in the next round of tests that I do. Thanks for the pull request!

[Filip]

No problem!
Wish to hear what you think of the solution.
Because it's a slightly different solution as the rest of the script, because of the sp_ineachdb on sys tables.

[Brent Ozar]

Looks good! I merged it into the dev branch, and it'll be in the August release with credit to you in the release notes. Thanks for solving this - I know it couldn't have been an easy problem. At least it wasn't for me, ha ha ho ho.