Issue 726 : BackupType - Option to use lower case in URL

[mdaniou]

Adding a bit of code to lowercase urls all the time. I hope this will answer this issue

[sethmgray]

I have similar requirement asking for ability to lower() the backup path. In our case we have Always On AGs that have databases that were not properly cased equivalently between restore operations by dbas and having ability to send at least the database name to lower or upper would help to guarantee the file has some consistent convention making its way to case sensitive systems (storage gateways and s3 in AWS in our case).

[olahallengren]

Would you like to have a parameter here to make the directory path lower case or upper case?

[sethmgray]

Would you like to have a parameter here to make the directory path lower case or upper case?

In our case it's best that the path and database name has separate params to put each to upper/lower, but the full path (including db name) would at least allow for predictable and repeatable casing

[olahallengren]

Another option could be to introduce new lower/upper case tokens in these parameters:
https://ola.hallengren.com/sql-server-backup.html#DirectoryStructure
https://ola.hallengren.com/sql-server-backup.html#FileName

[sethmgray]

I assume the addition of two casing versions of each token would be the most flexible and least/no impact to the procs arguments.

…

On Sun, Oct 27, 2024, 12:16 PM Ola Hallengren ***@***.***> wrote: Another option could be to introduce new lower/upper case tokens in these parameters: https://ola.hallengren.com/sql-server-backup.html#DirectoryStructure https://ola.hallengren.com/sql-server-backup.html#FileName — Reply to this email directly, view it on GitHub <#745 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPICOYHTCGIHVZCLGVWVNTZ5UUZBAVCNFSM6AAAAABNMVNWQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBQGE2DENZWGU> . You are receiving this because you commented.Message ID: ***@***.*** .com>

[olahallengren]

I assume the addition of two casing versions of each token would be the most flexible and least/no impact to the procs arguments.

It would be the most flexible, but also quite cumbersome to pass the parameters correctly, especially if you have both standalone databases and databases in availability groups.

The other option would be to introduce two new parameters, @DirectoryStructureCase and @FileNameCase, where NULL is the default (as today), but you could set them to LOWER and UPPER.