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.

NOTE

There are many options you can set, and the numbers that set them are
explained at the Microsoft site at the end of this article.

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.