What Type of Data is That?

By The Microsoft Scripting Guys

Welcome to Sesame Script, the column for beginning script writers. The goal of this column is to teach the very basics of Windows scripting for system administration automation. We’ll provide you with the information you’ll need to begin reading and understanding scripts and to start modifying those scripts to suit your own needs. If there’s anything in particular about scripting you’re finding confusing, let us know; you’re probably not alone.

Check the Sesame Script Archives to see past articles.

On This Page

What Type of Data is That?
What Is a Data Type?
What’s a Variant?
Why Do We Care About Data Types?
Forcing Data Types
What About...
Data Types and SDKs
Tune in Next Time…

What Type of Data is That?

The holiday season has just ended. We’re sure that for many of you, one of the joys of the season was putting together bicycles, playpens, and various other toys and contraptions with instructions that were ambiguous at best. Even if you don’t celebrate any of the end-of-year holidays, you can probably relate to “Insert bolt A into slot C. Tighten bolt B. - Bolt B? Where’s bolt B? Tighten it where?”

We know many of you have gone through the same type of confusion and frustration trying to write your own scripts, or even trying to modify the scripts you find in the Script Center. You go to the WMI SDK or the VBScript Language Reference and end up totally confused. So in this episode of Sesame Script, we decided to talk about interpreting the reference documentation so you can figure out how to call various methods and use various properties.

But we immediately ran into a stumbling block. It’s almost impossible to discuss deciphering an SDK if you don’t first understand data types. So first things first. If you understand data types (are you sure you understand them?), you can skip this article and read the next one, which really is on learning to read the reference docs. Honest.

What Is a Data Type?

A data type is, well, a type of data. A character string is a type of data; as a matter of fact, a single character is a type of data. So is a number. Even an object is a type of data. So some examples of data types are string, char, integer, and object. There’s also this odd thing called a Variant.

What’s a Variant?

VBScript uses one data type: a Variant. A Variant is VBScript’s way of saying it really doesn’t care about data types. So why do we care about them? We’ll get back to that question in a minute. Just trust us for now that we do need to care, at least a little bit.

Whenever you use a variable in VBScript, you name it anything you want and assign it any value you want. Even when you use Hungarian notation to name your variables, you don’t have to put the matching kind of data into the variable. For example, just because this variable is prefaced with str doesn’t mean you have to assign it a string:

strData = "a string of data"

You can also assign it a number:

strData = 4

Or even an object:

Set strData = CreateObject("Scripting.FileSystemObject")

The name is for your use only, VBScript really doesn’t care what you put in there.

Why Do We Care About Data Types?

So back to our question: why do we care about data types? Well, suppose you do something like this:

strData = "a string"
intData = 4
DataTotal = strData + intData
Wscript.Echo DataTotal

What should VBScript do with this? Are you expecting DataTotal to contain a string, such as “a string4”? Or are you expecting some sort of number? What if we do this:

strData = "23"
intData = 4
DataTotal = strData + intData
Wscript.Echo DataTotal

Will DataTotal contain “234” or 27? Or neither? Give it a try and see what happens.

Did you try it? That’s okay, we’ll wait.

Now that you’ve tried both scripts, you’ve discovered that the first one gives you an error:

C:\Scripts\test.vbs(3, 1) Microsoft VBScript runtime error: Type mismatch: 'strData'

Whereas the second script returns a value:

27

What’s going on? Well, VBScript is taking its best guess as to what you want to do. In the first script, VBScript couldn’t figure out what we were thinking when we tried to add a character string to a number. Not having any idea what we really expected from that, VBScript gave up and displayed an error message. In the second script, VBScript saw that the character string was made up of numbers, and that you wanted to add. So it decided that the quotes around the number must have been a mistake, that you really wanted a number not a string. With that in mind, it helpfully treated the string as a number and added the numbers for you.

Now for the real trick, try this one:

strData1 = "23"
strData2 = "4"
DataTotal = strData1 + strData2
Wscript.Echo DataTotal

What do we get back from this? No, we don’t get back 27 again. We get back 234. Why? Because VBScript saw that we had character strings in both values, so it went ahead and treated them like character strings and concatenated the two values. It didn’t need to ignore the quotes because both values were obviously strings, and VBScript knows that adding two strings is the same as concatenating them.

Forcing Data Types

Now, as much as you might want to put your trust in VBScript to guess correctly, that might not always be a good idea. You might want to, on occasion, actually tell VBScript what the data type is. Very straightforward, no guesswork. But how do we do that when we can’t specify a data type? By using some VBScript built-in functions created to solve just this problem.

Let’s take our last script, the script that concatenated our two number strings:

strData1 = "23"
strData2 = "4"
DataTotal = strData1 + strData2
Wscript.Echo DataTotal

What if we really wanted these strings to be treated like numbers? Well, yes, in our small isolated world of examples we could just remove the double quotes around the numbers. But let’s try to imagine a real-life scenario: You’ve read values in from a text file. You’re not sure whether VBScript will treat them as numbers or characters, and guessing could land you in a lot of trouble because you’ll be reporting these numbers to the Accounting department. So let’s tell VBScript that we definitely want these values to be treated as numbers:

strData1 = "23"
strData2 = "4"
DataTotal = CInt(strData1) + CInt(strData2)
Wscript.Echo DataTotal

Run this script and you’ll see that the strings were converted to integers, and the value of DataTotal is 27. VBScript has similar functions for converting strings, dates, and several other data types. And what if the strings didn’t contain numbers? Well, take a look:

strData1 = "string 1"
strData2 = "string 2"
DataTotal = CInt(strData1) + CInt(strData2)
Wscript.Echo DataTotal

CInt returns an error, because it can’t turn the string into an integer:

C:\Scripts\test.vbs(3, 1) Microsoft VBScript runtime error: Type mismatch: 'CInt'

What About...

What about dates and times and doubles and null values and…? Well, we’ve provided a general overview for you here just to introduce you to the idea of data types and how VBScript deals with them. There is more information on data types in the Scripting Guide, including extensive information on working with dates and times. Check out the More Information section for details.

More Information

Microsoft Windows 2000 Scripting Guide:

• VBScript Data Types

• Working with Dates and Times

• Working with Strings

• Working with Numbers

VBScript Functions - VBScript Language Reference

Data Types and SDKs

We now know that VBScript uses a Variant data type, and that you can use various VBScript functions to manipulate those data types if you need to. But what does this have to do with SDKs? We don’t want to get ahead of ourselves and spoil the fun for the next column, but let’s just take a quick peek at a portion of the WMI SDK:

class Win32_LocalTime : Win32_CurrentTime
{
  uint32 Day;
  uint32 DayOfWeek;
  uint32 Hour;
  uint32 Milliseconds;
  uint32 Minute;
  uint32 Month;
  uint32 Quarter;
  uint32 Second;
  uint32 WeekInMonth;
  uint32 Year;
};

This is the definition of the Win32_LocalTime class in WMI. (If you don’t know what a class is, read “Class is in Session.”) Each item listed within the curly braces {} is a property of that class. Win32_LocalTime is a pretty straightforward class, all the properties are defined as uint32. The uint32 data type is a 32-bit integer - or in human terms, a regular old number. So we know that if we read in the Day property of the Win32_LocalTime class, we’re going to get a number back.

Part of the reason the SDK shows this is because, as we already mentioned, it can be important to know what kind of data you’re getting back so you know what to do with it once you have it. Or if you’re setting the value of a property, you need to know what type of value you should be setting it to. This is a nice convenience, but it’s not the real reason you see uint32. If that was all there was to it, wouldn’t it be easier for the documentation to do something like this?

Class: Win32_LocalTime
Properties:
    integer    Day
    integer    DayofWeek
    integer    Hour
    ...

So then why uint32, and braces, and all that? Because WMI is not used exclusively for VBScript. Many programming languages, such as C++ and C#, require you to specify the type of a variable before you use it. This is known as “strong typing.” (In contrast, VBScript is “loosely typed.”) In strongly typed languages, you can’t just do something like this:

strHello = "Hello"

That one line is enough for VBScript to run successfully. However, in C# you would have to do this:

string strHello;
strHello = "Hello";

Yes, you could also do that in one line:

string strHello = "Hello";

The point is, you have to tell C# that you’re going to use that variable as a string. Not only that, but you actually do have to use it as a string. This will give you an error:

string strHello = 4;

The WMI SDK is written so everyone can use it, and for languages that are strongly typed, it’s imperative to know what the data type is, all the way down to uint32 (which, by the way, stands for unsigned 32-bit integer) and uint64 (you can guess what that one is).

Tune in Next Time…

In our next column we’ll explore the Language References and Software Development Kits in more depth. Soon bolt A will fit nicely into slot C. Well, maybe.