You've spent hours writing a script that will automatically delete old inactive user accounts in Active Directory (AD). You're a novice at writing VBScript code, but manually deleting the old AD accounts every month was so tedious that you knew writing this script would be worth the effort. You wait in excited anticipation as you run it on your test network, but—oh no!—your script has screeched to a premature stop. What went wrong? The possibilities are endless. However, the Pareto Principle (aka the 80/20 rule) dictates that most (around 80 percent) of the scripting errors will come from relatively few (around 20 percent) of the possible causes.
Several scripting experts recently talked about common errors they find when reviewing VBScript code on the job and for Windows IT Pro, Windows Scripting Solutions, and other publications. According to these experts and various articles, the most common VBScript syntax errors (errors that occur when the code violates the VBScript language's grammatical rules) and runtime errors (errors that occur when a script attempts to perform an action that the system can't execute) occur when scriptwriters work with variables, error-handling statements, quotes, and special and reserved characters.
Vexing Variables
You've just spent several hours hammering out lines of code that capture information for each printer in your multisite network. Windows Management Instrumentation (WMI) monikers, VBScript constants, and the strComputer, colPrinters, and printer variables fill your head, and your eyes hurt from staring at the screen. Finally, as you handle colPrinter in the last For Each...Next statement, you know that you're on the home stretch. You quickly finish the script and test it, but your hope of going home soon vanishes as the script ends abruptly.
What happened? The answer lies in what you just read. The previous paragraph contains an error that happens too often in scripts: misspellings. In one instance, the collection variable's name included the letter s (colPrinters), but in the other instance, that letter was missing (colPrinter).
"I think the most common problem I've seen is failing to use the Option Explicit keyword, then having the script fail because it uses a variable much like the one it's supposed to be using," says Michael Otey, president of TECA, a software-development and consulting company, and technical director for Windows IT Pro. This problem was also high on the lists of other scripting experts, including Steve Seguis, CEO and chief software architect of SCRIPTMATION, an enterprise system automation firm. "One of the most common problems I've seen with VBScript code is misspelled variables," says Steve. "For example, using a variable called oUser in one place, then trying to read it as oUsr in another. This type of problem can be easily corrected by forcing declaration of variables using Option Explicit."
VBScript can help you avoid misspellings. To use a variable in VBScript code, you simply assign it a value. You don't have to explicitly define (i.e., declare) the variables you use. However, just like eating vegetables or getting daily exercise, it's in your best interest to do so, although it isn't required.
To explicitly declare variables, you simply place the Option Explicit statement at the beginning of your script to tell the scripting engine that you want to allow only those variables that you've explicitly declared with Dim, Private, Public, and ReDim statements. If the scripting engine encounters an undeclared variable, you'll receive the Variable is undefined error message (error number 500) followed by the undeclared variable's name . This one little line can save you dozens of hours of frustrating debugging. Be aware that if you happen to have more than one undefined variable, the error message identifies only the first one found.
In VBScript, quotes (" ") must surround all strings. Using the Option Explicit statement not only catches undeclared variables but also strings not enclosed in quotes. For example, the code
Option Explicit
Dim strComputer
strComputer = PC1
results in a Variable is undefined error message because the scripting engine interprets PC1 to be a variable and not a string since it isn't in quotes. If you omit the Option Explicit statement in the previous code so that it reads
Dim strComputer
strComputer = PC1
WScript.Echo strComputer
an error doesn't result. Instead, the scripting engine automatically assumes you have two variables: strComputer and PC1. Thus, instead of seeing the equal sign (=) as an assignment operator and assigning the value of PC1 to the strComputer variable, the scripting engine reads = as the equal to operator and makes the strComputer variable equal to the PC1 variable.
Other problems can occur with variables. Have you ever received a Type mismatch or Name redefined error message? Here's a look at what causes these and several other variable-related errors:
Expected end of statement (1025). When a variable name contains an embedded period, you'll receive the Expected end of statement error message. This error message can also result from other errors, such as accidentally using a comma instead of a period in an object name.
Type mismatch (13). When you try to perform an operation by using variables that contain data inappropriate for that operation, you'll receive the Type mismatch error message. For example, the code
Option Explicit
Dim A, B, C, D
A = 25
B = 105
C = "Combined weight: "
D = A + C
WScript.Echo C & D
produces the Type mismatch error message because it's trying to add a string to a number. In "Quick Scripting Tips," April 2002, InstantDoc ID 24232, Christa Anderson recommends that you "Name variables according to the kind of data they represent (e.g., give strings names that begin with the letter s and objects names that begin with o). This practice makes debugging code easier. Some expressions won't work or will work differently with data of an unexpected data type. And if you know what data type you intended to feed a script, unraveling type-mismatch errors is easier."
The VBScript Coding Conventions section in the Windows Script (WS) 5.6 Help file (script56.chm) has a list of recommended prefixes that you can use for variables. For example, if you add the recommended prefixes to the previous code so that it reads
Option Explicit
Dim intA, intB, strC, intD
intA = 25
intB = 105
strC = "Combined weight: "
intD = intA + strC
WScript.Echo strC & intD
you'll probably immediately notice the error and change strC to intB in the sixth line.
Name redefined (1041). When a variable name isn't unique, you'll receive the Name redefined error message. Perhaps the easiest way to avoid this error is to use meaningful variable names. For example, instead of using names such as intA, intB, strC, and intD, you might use the names intMinniesWeight, intBrutusWeight, strLabel, and intBothDogsWeight, respectively.
This list of error messages is in no way exhaustive. You'll probably encounter many more types of error messages. The Learning Path box lists several resources that discuss common scripting error messages.
Ignorance Isn't Bliss
In scripting, what you don't know can hurt you. To avoid a script stopping when it encounters an offline computer, a nonexistent file, or another runtime error, some scriptwriters automatically include VBScript's On Error Resume Next statement at the top of their scripts. Bill Stewart, systems and network administrator for French Mortuary, says that always including this statement can do more harm than good. "While this causes the script to hop past runtime errors, it also skips errors you might not expect—syntax errors and undefined variables being two commonly skipped errors."
Stewart and other scripting experts recommend that you use On Error Resume Next sparingly to trap errors only when needed. You should place the On Error Resume Next statement immediately before the code that might cause a runtime error. Then, after that code, you should use the On Error GoTo 0 statement to reenable the default VBScript error handler.
Previous
Register
