[13.0.56 Pro] - BUG - Restore Database (MSSQL)

[13.0.56 Pro] - BUG - Restore Database (MSSQL)

We were trying to restore a live database to a different database name for debugging purposes using the context menu Backup and Restore in the Database Explorer. There were several issues:

#1. Even though the desired database was the active (connected) one and I right-clicked exactly that database, the Restore Database dialog was initially populated with the data of another database (the last one in the alphabetically ordered list of the databases). Regardless of which databases were right-clicked, the dialog always started with this database.
#2. When trying to change it in the dialog using the dropdown list for the Source Database, the list was "unordered". That might not matter when there's only a few databases, or you're looking for a database with a short name, typing its name might work, but when there are dozens or even hundreds of databases (eg. with yearly and/or quarterly data, being different only at the last few characters of the name), all scattered around in the list, that might prove a challenge.

Now, the first 2 were only a nuisance, but the #3 is potentially dangerous.

#3. I guess not typing anything into the Destination Database input box would restore "in-place", that is, it would overwrite the existing database (provided the Options / Overwrite checkbox is checked, I hope). But since we needed to debug something while keeping the original intact, I typed the database name + debug (resulting in the new name "track_db_debug"). And when I checked the SQL pane to see what it would execute, I saw this:

	Code:
	USE [master] GO RESTORE DATABASE [track_db] FROM DISK = N'F:\MSSQLBCK\DKV-GPSDB\track_db\FULL\DKV-GPSDB_track_db_FULL_20250508_001657.bak' WITH FILE = 1 ,MOVE N'track_db' TO N'D:\MSSQL\Data\track_db_debug.mdf' ,MOVE N'track_db_log' TO N'E:\MSSQL\Log\track_db_debug_log.mdf' ,NOUNLOAD, STATS = 5 GO

Notice, that it shows

	Code:
	RESTORE DATABASE [track_db]

instead of

	Code:
	RESTORE DATABASE [track_db_debug]

That most likely won't execute, complaining about not being able to restore the database without "WITH REPLACE". Obviously, we did not try that on a live production database. Who would do such a thing, right?
Now, if this is done by an inexperienced developer, the greenie might just simply click the WITH REPLACE, because that's what the non-dba bystander told him after reading the error message (the stuff executes successfully this time), and they call it a day. Except, when trying to connect to the shiny new database, it isn't there, and when checked, in the original database, the data since the last backup isn't there either. Panic kicks in, someone restores the original database (again, instead of simply re-attaching the existing files), this time with the "correct" file names, and all the current data after the last log backup goes to hell in a handbasket. This is a theoretical scenario, of course. Never happened. But only because someone shouted STOP like it was the safe word for BDSM, and knocked the greenie's hand from the keyboard, seeing what they were about to do. Might have broken a finger or two. Luckily, not mine.

#4 just as a gratis. When the backup is done to multiple files (let's say 8), the generated statement only fetches the first one and is incorrect. It only gives an error message:

	Quote:
	Msg 3132, Level 16, State 1, The media set has 8 media families but only 1 are provided. All members must be provided....

instead of restoring the database.

Thank you so much for letting us know. We are investigating the reported issues.