Repository navigation
[BUG] PMLite: database names after renaming #3876
Description
Component
Lite
Performance Monitor Version
3.8.0
SQL Server Version
Azure SQL Db
Windows Version
W11
Describe the Bug
I have received the requirement to rename some of databases, it was done one month ago.
Steps to Reproduce
Rename some databases, go to FinOps, and TabPages:
- Database sizes: OK, db names were renamed.
- Database Resources: OK
- Locking & Contention: the old database names are in the grid
- Storage growth: OK
Expected Behavior
The db names must be
Actual Behavior
In some pages the still old db names
Error Messages / Log Output
Screenshots
No response
Additional Context
No response
Activity
erikdarlingdata commentedon Sep 22, 2026
Claimed (pm-user-worker seat). The report's own discriminating fact drives the investigation: three of four FinOps tabs re-read the renamed databases correctly and only Locking & Contention shows month-old names, which rules out a shared rename-propagation failure and points at that one grid's binding — a name denormalized at capture and never re-resolved, a stale name cache on the write path, or a read-time join against a snapshot only some readers refresh. First step is diffing how Locking & Contention sources its database label against how Database Sizes (demonstrably correct) sources its, then fixing at whichever layer the stale name actually enters. Root cause will be stated here before the fix lands.
erikdarlingdata commentedon Sep 22, 2026
Root cause found (file:line against dev@90f955b3a): the Locking & Contention read — and its database SELECTOR — resolve "latest" per database NAME: Lite/Services/LocalDataService.FinOps.IndexObjects.cs:223-226 runs MAX(collection_time) GROUP BY database_name (joined at :248), so every name the store has ever seen keeps its own immortal "latest" group. A renamed database's old name still owns the last pre-rename capture, which is truthfully "the latest row for that name" forever — a month later it renders beside the new name as a peer, and the dropdown still offers it. The three working tabs anchor on the SERVER's latest capture (or a sliding window), so old names dropped out on the next pass — exactly the four-tab split you reported. Nothing was wrong with rename propagation: the collector re-derives the name via DB_NAME() on every pass, so post-rename rows always carried the new name. The per-name grouping also buys nothing for live databases: one collector run stamps all its databases with a single collection_time, so the per-name MAX equals the server-wide MAX for anything currently collected. Fix: both the grid and the selector now anchor on the server's latest capture, the same resolution the working tabs use; capture-time names stay in the store untouched. Note: the Darling edition ports this same read verbatim (viewer + MCP surface) — that gets its own issue and fix.
The Locking & Contention grid stops resolving "latest" per database n…
erikdarlingdata commentedon Sep 22, 2026
Fixed in the squash above (PR #3877). The Locking & Contention grid and its database selector now anchor on the server's latest capture — the same resolution the three tabs that worked for you have always used — so renamed-away names drop out on the next collection pass. Your capture history is untouched; the grid just stops reading the past as the present. The fix ships with the next nightly build. The Darling edition carried the same ported read; that fix is #3878, in flight now. Thanks for the four-tab detail in your report — it was the diagnosis.
Darling's four object-locking reads anchor on the server's latest cap…
ZedZipDev commentedon Sep 22, 2026
Thank you @erikdarlingdata . And please re-check Auto-Refresh value. After PMLite restart it works fine, but after Update the version and start the new one .