I was under the impression that the Backup Path button / option was added as a result of one of my feature requests. The feature request was under the context of a developer or support desk or person who took a copy of production data and is trying to restore a database on a physically different server.
The intent was to override the backup paths that were contained IN the .bak file (which are very likely invalid on the destination server) with the current physical location of the .bak file.
Scenario: Production Server has .mdf on Drive D:\SQLData, .ldf on Drive E:\SQLLogs
.bak file is created.
On the Development computer:
User copies the .bak to their C:\SQLData folder. (They have no D drive, no E drive)
In Toad, user goes to restore that database. Toad automatically loads the backup paths from IN the data file – which on this computer are useless.
Objective: Reduce/eliminate the time the developer / tech has to spend manually editing the paths of each file to some location that actually does exist on his machine by clicking one button: BackupFilePath – to just use the path where the user has placed the .bak file.
It is VERY RARE for us to EVER use the restore Database Option from within Toad on the actual production servers.
It is EXTREMELY COMMON for us to use the restore database option on development computers, support computers, etc. The whole point of the button is to make the restore process faster on machines where those original paths do not exist.