Here's a strange one.
I have a script with a lot of ifs in it. In order to track whether the script has gotten to a certain point and made the requested changes, I have added a statement deep in the bowels of the script to set a variable name "ChangeMade" to 1. I can then test on this variable later in the script to see if something was actually done, or if the script ran through all the ifs without actually scoring a hit.
Basically, like this:
So, here's the funny part: I know that the script does something, because the "write to procedure log" part actually writes the correct text to the log. However, once it gets to the If #ChangeMade# test, it complains that this variable does not exist, despite the fact that it must have been created and set as it follows immediately after writing to the log.
The other funny thing is, if I add a statement at the beginning of the script to to set the variable to zero, then the IF statement will always evaluate to zero (else) despite the fact that the variable *must* have been changed inside of the IF statements.
It is as if the IFs are spawned off as separate scripts, thus creating a new variable with the same name "local" to the IF statement, rather than using the variable as a global variable for the entire script ...
Can any test a similar script to see if they are seeing the same results?
Any ideas on what is going on? Is my local/global variable theory correct? If so, that is seriously wrong ...
I noticed this also. It appears that the variable is going out of scope as you move from one if block to the next. The variable stays in scope if the first if block calls another procedure with the second if test in it. Haven't tried it, but perhaps setting the variable's value to something before the first if block would keep it in scope.
It's a bit more work, but I'd use a more thorough method for testing for changes... For example, I write WHAT changes were made to a log file using the command shell execution ECHO blah >> file, and they're kind of script-specific - so when I'm testing whether a change has been made, I test for WHAT change was made using tests against the file itself rather than trusting built invariables.
To ensure I don't have false-positives, I delete the log file as the first step of the script, so it's clean for that execution. I got this idea from the Office 2010 deployment script on the old forums -- that script didn't work for me, but the theory was solid and I ran with it.
I have used this method previously and it appears to work.
I was really hoping to not have to resort to dumping data into a file or the registry for this simple task ...