SQL Server Reference Guide

Data Management Objects: Scripting

Last updated Mar 18, 2005.

We're at the end of a long journey. I have covered several DMO topics in the past few articles. I've shown you how to gather database information, how to perform maintenance, how to create a log file of these processes, how to run a SQL Query on an object and also how to control security with the DMO library.

In this article, I show you one of my favorite and most often used parts of SQL DMO programming: how to script almost any item in SQL Server to a variable, and then on to a file.

At first glance, it appears that scripting might be a nice feature, but not all that earth-shaking. After all, is scripting something that you really need to automate? You bet!

The first use for scripting a database is source-control. SQL Server doesn't have a built-in mechanism to freeze the "version" of a database, so when changes are made to an object, there's no way to capture the structure of the database object before and after the change. Putting things back the way they were becomes an issue.

You can, however, write a very simple program that scripts a database or database object to a file with a date, makes the change in DDL, and then scripts the object again with the newer date. You can then use the scripts to "roll back" the database or object to its previous state. You can also script the entire database whenever a new version is released with all its objects to a file to be saved in a source-control system. You would then have a database version, independent of any data.

Another use for scripting is to simplify the tracking of security I discussed in my last article. You may recall that there are quite a few steps to detail the rights a user or group has. If, instead, you script the user with all his permissions to a file, you can check those files for deltas, or use them to migrate databases.

You can also use DMO scripting to create migration scripts for a development environment. If you don't currently have a method of capturing all the changes the developers have made in a database object, you can create an ALTER statement that morphs the current object into the latest version.

The most ambitious purpose for which I've used for DMO scripting is to compare databases or database objects. Using DMO, I created a script file of one database, and then created a script file of a second database. I then used regular expressions to compare the text files to see where the objects were different. This took a bit of work to get right, but I can't tell you how many hours it saved me.

So, let's take a look at some code that shows how easy this is. Once again, I'll use a single example and let you extrapolate to any of the objects that use the script method (most do). You can also use any of the iteration methods I've shown you previously to walk through as many collections of objects as you like, creating scripts along the way.

The following code scripts out a table – the authors table in the pubs database, in this case – to a message box:

' Get and set a SQL DMO server object, and connect
' to the local server instance
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.LoginSecure = True
oServer.Connect "(local)"

' Get and set a database object
Set oDatabase = oServer.Databases("pubs")

' Get and set a table object
Set oTable = oDatabase.Tables("authors")

strMsgText = oTable.Script(4)



' Display. You could also send this to a file
MsgBox strMsgText

'Clean up
Set oTable = Nothing
Set oDatabase = Nothing
Set oServer = Nothing

When you run this code, you'll see a message box with all the text for recreating the authors table. Notice the line that reads:

strMsgText = oTable.Script(4)

What I did here was use a text variable to hold the results of the script on the table object I had populated in the line before. The number that follows sets the options I want in the script, such as headings, drop statements, if exists, and so forth. The number 4 sets the script to use the default options.

To add options together, simply add the numbers. Adding a heading (1) to the default options (4) that I have here means that the number would change to (5).

The real power is that you can script just about any object, from databases to a triggers.

Let's kick this up a notch. While it's nice to have the script show up on a message box, it would be far more useful to have it in a text file, ready to run. You could use the file operations I showed you in articles past, but Microsoft knows that the reason for most scripting is to get the object out to a file. For that reason, they added an option to the script method that automatically formats the statement and sends it on to a file. All you have to do to invoke this process is to add the script location to the end of the script method, like this:

strMsgText = oTable.Script(4, "C:\temp\Authors.SQL")

Run the code again with this replacement; the output goes to the screen and to the file specified.

Let's address one more issue with this code. Earlier, I mentioned that you have to take the number that represents the options for scripting and combine them to mix your options. You can store these numbers in a single place in your code with friendlier names, and then use those names. This is done using a special kind of variable that doesn't change, called a Constant. You declare a constant in VBScript with Const =. After that, you can put any value you like.

But what if you want both the granularity the number provides, and friendly names? Do you have to declare each and every combination that the numbers might represent and give it a name? Heavens, no.

When I said that you add the numbers to create a combination of options that was only partly true. What I mean is that the effect of adding the numbers is correct, but you technically aren't adding them; you're combining them. That might seem like a small distinction, but it isn't.

You're actually creating a mask, which has more to do with binary math than with decimal-based math. The upshot of this is that you don't add the words you create as constants; you use the mathematical OR function to create the mask. It's the same effect as combining the numbers.

In the following code, I tie all this together. I added constants to use throughout the code, and then set the script method to send the result to a file called Authors.SQL in the c:\temp directory:

' Get and set a SQL DMO server object, and connect
' to the local server instance
Set oServer = CreateObject("SQLDMO.SQLServer")
oServer.LoginSecure = True
oServer.Connect "(local)"

' Get and set a database object
Set oDatabase = oServer.Databases("pubs")

' Get and set a table object
Set oTable = oDatabase.Tables("authors")

' Now let's set up all the scripting options we need:
Const SQLDMOScript_DatabasePermissions = 32 'Generate Transact-SQL database privilege defining script. Database permissions grant or deny statement execution rights.
Const SQLDMOScript_Default = 4 'Scripts the Object with default options.
Const SQLDMOScript_Drops = 1 'Generate Transact-SQL to remove referenced component. Script tests for existence prior attempt to remove component.
Const SQLDMOScript_IncludeHeaders = 131072 'Generated script is prefixed with a header containing date and time of generation and other descriptive information.
Const SQLDMOScript_IncludeIfNotExists = 4096 'Transact-SQL creating a component is prefixed by a check for existence. When script is executed, component is created only when a copy of the named component does not exist.
Const SQLDMOScript_Indexes = 73736 'SQLDMOScript_ClusteredIndexes, SQLDMOScript_NonClusteredIndexes, and SQLDMOScript_DRIIndexes combined using an OR logical operator. Applies to both table and view objects.
Const SQLDMOScript_NoCommandTerm = 32768 'Individual Transact-SQL statements in the script are not delimited using the connection-specific command terminator. By default, individual Transact-SQL statements are delimited.
Const SQLDMOScript_ObjectPermissions = 2 'Include Transact-SQL privilege defining statements when scripting database objects.
Const SQLDMOScript_OwnerQualify = 262144 'Object names in Transact-SQL generated to remove an object are qualified by the owner of the referenced object. Transact-SQL generated to create the referenced object qualify the object name using the current object owner.
Const SQLDMOScript_Permissions = 34 'SQLDMOScript_ObjectPermissions and SQLDMOScript_DatabasePermissions combined using an OR logical operator.
Const SQLDMOScript_PrimaryObject = 4 'Generate Transact-SQL creating the referenced component.
Const SQLDMOScript_TimestampToBinary = 524288 'When scripting object creation for a table or user-defined data type, convert specification of timestamp data type to binary(8).
Const SQLDMOScript_ToFileOnly = 64 'Most SQL-DMO object scripting methods specify both a return value and an optional output file. When used, and an output file is specified, the method does not return the script to the caller, but only writes the script to the output file.
Const SQLDMOScript_UseQuotedIdentifiers = -1 'Set to use Quoted Identifiers

strMsgText = oTable.Script(SQLDMOScript_IncludeHeaders Or SQLDMOScript_Default, "C:\temp\Authors.SQL")



' Display. You could also send this to a file
MsgBox strMsgText

'Clean up
Set oTable = Nothing
Set oDatabase = Nothing
Set oServer = Nothing

I hope this series of articles has been helpful. You can use SQL DMO programming to help you a great deal in your DBA tasks.

Online Resources

The full documentation for the SQL Server Object Library can be found here.

The specifics for the scripting method is here.