Home > Articles > Databases > SQL Server

SQL Server Reference Guide

< Back Page 210 of 361 Next >

Data Management Objects

Last updated Mar 28, 2003.

By now, you've probably seen that there are lots of ways to interact with SQL Server. There are the built-in tools like Enterprise Manager and Query Analyzer, of course, and you've also got the command line tool, osql. In addition, you may have played with SQL Server programming. You might also have spent some time working with the Web-SQL interaction. I've even shown you how to use e-mail as a client.

In this article, we begin to explore another way to access Microsoft SQL Server: Data Management Objects, or SQL-DMO. SQL-DMO is a set of libraries used to talk to SQL Server objects, from the server to the tables, from the user accounts to the backup engine, and more. In fact, most of the other tools use DMO to do the things a DBA requires.

I'll divide SQL-DMO into two broad categories: Management and Data Access. I'll show you how to use many of the commands SQL-DMO provides to manage your server or run any T-SQL command you'd like. We'll get started by preparing the environment and learning some basic concepts.

As I mentioned, SQL-DMO is a set of Dynamic Link Libraries (DLLs) that you reference within code. Don't worry; you won't have to learn a programming language or even install a programming environment on your system to use SQL-DMO. If you've got the SQL Tools installed on a standard Windows 2000 or XP system, you already have everything you need.

It might be that you don't have the SQL tools installed your system. If that's the case, locate the following files on your SQL Server system and copy them to your system. Only one file has location dependence, I'll point that one out:

TIP SQLDMO.RLL
TIP SQLRESLD.DLL
TIP SQLSVC.DLL
TIP SQLSVC.RLL
TIP SQLWID.DLL
TIP SQLWOA.DLL	TIP This needs to go in the system path directory
TIP W95SCM.DLL

Once these files are in place, use REGSVR32.EXE to register each of the DLLs.

NOTE

Again, you only need to do all this if you don't have the SQL Tools (such as Enterprise Manager or Query Analyzer) installed. If you have any of those, you already have what you need.

Next, check to see whether you have a suitable coding environment set up on your system. Open up notepad, and type in this (very complex) code:

MsgBox "Hello there!"

Save that as a file in the root of C: (or somewhere you can get to it easily from a command prompt) with the name test.vbs. Open a command prompt, find that directory, and type this:

TEST.VBS

And press Enter. If a popup box greets you, you're all set. If not, you might need to install Windows Scripting.

With these two configuration points set, you should be ready to use SQL-DMO. You'll use it through programming. If you're already familiar with development work, these articles will show you the uses of SQL-DMO; if you're not, you should be able to pick up enough programming to work with SQL-DMO.

Throughout this article (and the ones that follow) I use VBScript to access SQL-DMO, but that's just my choice. Other languages, such as Jscript and Perl, have the ability to call the SQL-DMO libraries. You also have the full gamut of compiled languages to draw upon to write DMO code, such as Visual Basic.NET and C#. The difference with those languages is that you set a reference to the SQL-DMO library, and the various objects we'll discuss are available from then on. Using a scripting language has the advantage of being very portable, and can also be called from the command-line or even in a web page.

The DLLs you installed earlier provide access to lots of SQL-DMO objects. Objects in this type of programming are just like physical objects, in that they have properties and methods. Let me explain what that means.

Let's take a physical example: a refrigerator. A refrigerator has a color, size, model, shape, and so forth. Let's call these attributes properties.

Refrigerators also do things, such as store, chill, and freeze. Let's call these actions methods.

Programming objects are just like that. They have things you can read or set (properties) and things that they do (methods). A group of programming objects is often grouped into a library – which brings us around to the DLLs we installed earlier.

Let's extend our analogy a little further. A refrigerator is a large object, but is made up of other objects as well, such as an ice-maker. To get to the ice-maker, you have to access the refrigerator object first.

Keep those concepts in mind as we move along.

Let's take a look at a programming example. If your system passed the tests I mentioned earlier, then you can type this code in (with a couple of exceptions). First, the code:

Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.LoginSecure = True
oServer.Connect "(local)"
MsgBox oServer.Name
Set oServer = Nothing

Let's dissect this line by line, using our analogy to help. First, just like the refrigerator, we have to have one to actually use it. The first line of code takes care of that for us:

Set oServer = CreateObject("SQLDMO.SQLServer")

This line uses a VBScript command (Set) to declare a variable (oServer) and set that variable to a library function – in this case, the SQLDMO library. Within that library, there are lots of sub-objects, like the refrigerator's ice-maker. The object we need to access first (like opening the door of the freezer) is the SQLServer object.

So, all we've done here is to create a variable and set it to a SQL Server using SQL-DMO. That's a lot of work in one line of code!

The magic part is the CreateObject() function. That verb tells VBScript to create an object for use. By piping that back into the variable, the single oServer object now contains all the things that the SQLDMO.SQLServer objects have. It's sort of like going to a home store and buying a particular refrigerator. Only in this case you've named the fridge, which is kind of strange!

The next two lines have to do with connecting to the server, just as we do when we use Query Analyzer or Enterprise Manager:

oServer.LoginSecure = True
oServer.Connect "(local)"

I set the system to use a Windows login here (I'll show you another way in another article) and the name of my server (local).

You can see here an example both of a property and a method. The .LoginSecure part is a property, which is set to "True". That's similar to the color property of a refrigerator being set to "white."

The .Connect part of the code is a method. The SQLServer object has many verbs that cause action, and one of them is this connection command. This command takes a qualifier: the name of the server.

There, we've connected to the server and its waiting for us to do something with it. The next line displays the name of the server, again using a property:

MsgBox oServer.Name

The MsgBox part is a VBScript command that displays text in a message box on the screen, and we use the .Name property of the SQLServer object (represented here by the oServer variable we made) to get the name. You can see by this example that we can both get (.Name) and set (.LoginSecure) properties. Some properties are read-only and you can set others; in some cases, it changes based on where you are in the code.

We're done with the server, for now. Just like in the kitchen it's important to "close the refrigerator door" when you leave, which is what the last line does:

Set oServer = Nothing

This command "destroys" the oServer variable and all the resources it had. This is a good practice to follow. Any object you declare and set should be torn down when you're done.