Invoke-DbaDbUpgrade - Leave the database context of the caller alone

[andreasjordan]

Type of Change

• Bug fix (non-breaking change, fixes Invoke-DbaDbUpgrade - Leaves the connection pointing at the upgraded database #10556)
• Pester test is included

This is also the first command of bucket B of #10555. It deliberately carries no closing keyword for #10555: that issue was closed by accident when #10580 merged, because "fixes #10555 in part" is read as a plain "fixes" by the linking parser. Buckets B and C are still open.

Purpose

Invoke-DbaDbUpgrade handed the connection back pointing at the database it had just upgraded. This is the command from the provisioning script in #10555 that started the whole workstream, and it is a bucket B site, so the script method fix in #10579 does not reach it.

Approach

Two independent causes, and fixing either one alone leaves the leak in place under some parameter combination.

1. The four maintenance statements. They ran through SMO's own Database.ExecuteNonQuery, which issues a USE on the execution manager of the database - the connection context of the parent server, which belongs to the caller - and never switches back. They go through our Invoke script method now, which since #10579 restores the previous database in a finally. The statements still run in the database they always ran in; nothing else about them changes.

2. Enumerating $db.Views moves the connection just as well. This one is worth flagging beyond this command, because it is not in the inventory on #10555 and it cannot be fixed by any script method - it is not a call we make, it is a property getter. Measured on SQL Server 2019 with -NonPooledConnection, reading DB_NAME() on the caller's connection afterwards:

db.Views                      master -> leaked
db.Tables                     master -> leaked
db.StoredProcedures           master -> leaked
db.Users                      master -> leaked
db.Schemas                    master -> leaked
db.Roles                      master -> leaked
db.FileGroups                 master -> leaked
db.Tables[0].Columns          master -> leaked
db.Size (a plain property)    master -> ok
db.Refresh()                  master -> ok

So the command reads the database of the caller before any work starts - not just before the view refresh, or a statement that already moved the connection would be recorded as "what the caller had" - and puts it back around the view refresh, in a finally, case sensitively, exactly as Set-DbaTempDbConfig does since #10580. A failing restore warns rather than throwing, so housekeeping can never become the outcome of the command.

Tests

Three integration contexts in tests/Invoke-DbaDbUpgrade.Tests.ps1, all against a non-pooled connection, because a pooled one that closes between two calls reconnects at its default database and hides the leak:

• the upgrade itself, asserting the compatibility level really moved and that every maintenance step reported Success - a command that did nothing cannot leak, so without this the leak assertion would pass for the wrong reason
• the caller sitting in tempdb and using -Force, which fails for a fix that restores "to master" instead of restoring what the caller had
• -NoRefreshView -Force, the one case the restore around the view enumeration cannot cover, so the statements have to put the database back themselves

Verified to have teeth, in the lab against SQL03\SQL2019:

state of the branch	result
both halves	9 passed, 0 failed
Invoke reverted to ExecuteNonQuery	1 failed (the -NoRefreshView context)
restore around the view enumeration removed	2 failed (the other two contexts)

Commands to test

$server = Connect-DbaInstance -SqlInstance $instance -NonPooledConnection
$null = Invoke-DbaDbUpgrade -SqlInstance $server -Database <a database below the compatibility level of the instance>
$server.ConnectionContext.ExecuteScalar("SELECT DB_NAME()")   # master, was the upgraded database before

---

This text was created by Claude and reviewed by Andreas Jordan.

[andreasjordan]

Closing this in favour of #10603.

The fix for Invoke-DbaDbUpgrade is included there unchanged in behaviour, with one difference: the block that puts the database of the caller back is now the private function Restore-DatabaseContext instead of a copy inside this command. #10603 fixes nine more commands the same way, and they all need that function, so the two could not be opened separately without a merge order that has to be got right by hand.

Everything measured and tested here still applies and is repeated in the body of #10603.

---

This text was created by Claude and reviewed by Andreas Jordan.