-
Notifications
You must be signed in to change notification settings - Fork 993
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sp_databaserestore don't see backups which consists of more than 10 backupfiles when using @stopAt #3156
Comments
Sorry to hear about that! Just to set expectations - because there isn't an exact script I can run to reproduce this quickly, this isn't something I can knock out fast. There are a few options to move forward:
|
I'll try to produce a fix for this |
This will fix the problem:
|
Hmm - are you sure that works if there's only, say, 5 files? It looks suspicious that these two lines don't match:
and
|
I've succesfully tested this with a backup of 15 backupfiles and one with 3 backupfiles. I tried to combine these 2 situations in one line of code, but I gave up. The 2nd delete only works for 10+ backupfiles (2 numbers before the ".bak" ) |
Haven't bumped into this one, but the same problem is probably also in this line:
|
Thanks for the pull request! Looks good, merged into the dev branch, will be in the December release with credit to you in the release notes. Yeah, I won't fix the 10+ diff files one - I'll leave that for someone else in case they're bananas enough to use 10+ diff files, heh. |
Version of the script
8.11
What is the current behavior?
a) If there are more than 9 backupfiles and @StoPAt is defined the cleanup part (line 638-647) will delete all rows, resulting in "no backup found"
b) As a result, if you use @maxfilesize (in the procedure databaserestore from Ola) and the number of files changes to 10 or more, the sp_databaserestore procedure will only see the backups with < 10 backupfiles
If the current behavior is a bug, please provide the steps to reproduce.
(Finding A can only be tested with a new database)
What is the expected behavior?
correct determination of the backupfile to use
Which versions of SQL Server and which OS are affected by this issue? Did this work in previous versions of our procedures?
tested with SQL2019, bug also appeared on previous version
The text was updated successfully, but these errors were encountered: