v1.7.2
Four fixes since v1.7.1. No breaking changes, no config or schema changes — upgrading is a straight swap of the exe.
Every one of these was found by asking whether an already-fixed bug had siblings. It did. Three times.
The one worth upgrading for
The confirmation banner could name a different instance from the one the restore would run against.
The red panel above Execute is the last thing you read before an irreversible write, and it is worded the way it is for a reason: two hostnames can differ by a single character.
It named the instance the app last connected to. The restore ran against the instance selected as the target — and those are set in different places. Connect to SRV01 on the SQL Servers screen, come to Restore, change the target to SRV02 using the step this screen invites you to use, and arm: the banner said SRV01. The restore ran against SRV02.
Naming the wrong instance there is worse than naming none, because it actively reassures. The name now follows the target wherever it is set, and disconnecting clears it instead of leaving the last one standing.
Leaving a screen no longer throws away what you were doing
Navigating between screens re-reads the saved servers and containers, so that anything added elsewhere shows up. Each screen then re-selected what you had chosen — and could not tell that re-selection apart from you choosing something different, because the config hands back a fresh copy every time. So the screens did what they should do when you genuinely change your mind: they cleared.
On the Restore screen that meant the loaded backups, the timeline, the armed Execute, the missing-backup answer and its comparison — plus a fresh connection to the target instance, every visit. Reading a container of 98 headers takes minutes; glancing at Browse Backups to check a filename left "Load Backups" as the only thing on screen.
Worst on the missing-backup panel, because going away is how it is used: it names the transaction logs that never reached the container, hands you a script to copy them, and waits for you to come back and press rescan. Coming back was what cleared the answer the rescan compares against — so it reported everything as still missing however much had arrived.
On the Back Up screen it meant your database ticks. This is the screen for ticking twelve of forty databases before a patch window, and a glance at another screen emptied all twelve without saying anything.
Both now keep what you chose. Lists are still re-read, so a database or container created since your last visit still appears, and genuinely changing the server, container or source still clears everything — which is correct, and is why the clearing was there.
Finishing the missing-transaction-log check
The check that finds log backups which never reached your container now closes the loop. After you run the copy script it can answer the only question you actually have — did it work — instead of re-listing what is still missing. Five files still outstanding looks identical whether eighteen arrived or none did.
It counts by which files arrived rather than how many, so a retention job trimming an old log between checks is not mistaken for a successful copy, and backups taken since the last check are reported separately: nothing went wrong, there is simply more now.
Under the hood
Eleven new tests, each confirmed to fail against the unfixed code before the fix went in. 2,257 passing.