As indicated in the previous post, a simple upgrade that required no Database work has taken up time across multiple days. I should really point out that DAY 1, DAY 2, etc is really a matter of a couple of hours per day, if that. And as promised…
DAY 4
So, after a little bit of research, it turns out that a batch file interprets a comma [,] as a delimiter when passing it in. So, when we were passing the connection string to the batch file, we needed to include the port number. In this case let’s say DBSERVER,12345. The batch file was splitting that and sending 12345 as the second parameter. Easy enough fix, let’s wrap that in quotes [“]! Well, that worked, sort of, but not really. When you use string comparisons in your batch file that looks like
@IF "%1" == "/?" GOTO PrintHelp
the end result is really
@IF ""DBSERVER,12345"" == "/?" GOTO PrintHelp
which of course results in an error. Luckily, there are ways around it [resource]. If you use the following
@IF "%~1" == "/?" GOTO PrintHelp
it looks to see if the parameter is surrounded by quotes, if so it removes them and places them in the correct variable placeholder. Wonderful thing about this? If the quote marks aren’t there, it still works! So the end result was changing a half dozen lines in various batch files in order to run the Database update scripts and then the actual software upgrade ran like a charm. I’m not certain why the solution we found wasn’t implemented from the get go. It is quite possible that a large section of the clientele have an environment this is a single server instance and they’ve just never ran across it before. Either way, I felt a sense of accomplishment in figuring out exactly why it wasn’t working. I hope my hard work and frustration can pay off for someone else.
