Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
- Microsoft SQL Server Programming
- Performance Tuning
- Choosing the Back End
- The DBA's Toolbox, Part 1
- The DBA's Toolbox, Part 2
- Scripting Solutions for SQL Server
- Building a SQL Server Lab
- Using Graphics Files with SQL Server
- Enterprise Resource Planning
- Customer Relationship Management (CRM)
- Building a Reporting Data Server
- Building a Database Documenter, Part 1
- Building a Database Documenter, Part 2
- Data Management Objects
- Data Management Objects: The Server Object
- Data Management Objects: Server Object Methods
- Data Management Objects: Collections and the Database Object
- Data Management Objects: Database Information
- Data Management Objects: Database Control
- Data Management Objects: Database Maintenance
- Data Management Objects: Logging the Process
- Data Management Objects: Running SQL Statements
- Data Management Objects: Multiple Row Returns
- Data Management Objects: Other Database Objects
- Data Management Objects: Security
- Data Management Objects: Scripting
- Powershell and SQL Server - Overview
- PowerShell and SQL Server - Objects and Providers
- Powershell and SQL Server - A Script Framework
- Powershell and SQL Server - Logging the Process
- Powershell and SQL Server - Reading a Control File
- Powershell and SQL Server - SQL Server Access
- Powershell and SQL Server - Web Pages from a SQL Query
- Powershell and SQL Server - Scrubbing the Event Logs
- SQL Server 2008 PowerShell Provider
- SQL Server I/O: Importing and Exporting Data
- SQL Server I/O: XML in Database Terms
- SQL Server I/O: Creating XML Output
- SQL Server I/O: Reading XML Documents
- SQL Server I/O: Using XML Control Mechanisms
- SQL Server I/O: Creating Hierarchies
- SQL Server I/O: Using HTTP with SQL Server XML
- SQL Server I/O: Using HTTP with SQL Server XML Templates
- SQL Server I/O: Remote Queries
- SQL Server I/O: Working with Text Files
- Using Microsoft SQL Server on Handheld Devices
- Front-Ends 101: Microsoft Access
- Comparing Two SQL Server Databases
- English Query - Part 1
- English Query - Part 2
- English Query - Part 3
- English Query - Part 4
- English Query - Part 5
- RSS Feeds from SQL Server
- Using SQL Server Agent to Monitor Backups
- Reporting Services - Creating a Maintenance Report
- SQL Server Chargeback Strategies, Part 1
- SQL Server Chargeback Strategies, Part 2
- SQL Server Replication Example
- Creating a Master Agent and Alert Server
- The SQL Server Central Management System: Definition
- The SQL Server Central Management System: Base Tables
- The SQL Server Central Management System: Execution of Server Information (Part 1)
- The SQL Server Central Management System: Execution of Server Information (Part 2)
- The SQL Server Central Management System: Collecting Performance Metrics
- The SQL Server Central Management System: Centralizing Agent Jobs, Events and Scripts
- The SQL Server Central Management System: Reporting the Data and Project Summary
- Time Tracking for SQL Server Operations
- Migrating Departmental Data Stores to SQL Server
- Migrating Departmental Data Stores to SQL Server: Model the System
- Migrating Departmental Data Stores to SQL Server: Model the System, Continued
- Migrating Departmental Data Stores to SQL Server: Decide on the Destination
- Migrating Departmental Data Stores to SQL Server: Design the ETL
- Migrating Departmental Data Stores to SQL Server: Design the ETL, Continued
- Migrating Departmental Data Stores to SQL Server: Attach the Front End, Test, and Monitor
- Tracking SQL Server Timed Events, Part 1
- Tracking SQL Server Timed Events, Part 2
- Patterns and Practices for the Data Professional
- Managing Vendor Databases
- Consolidation Options
- Connecting to a SQL Azure Database from Microsoft Access
- SharePoint 2007 and SQL Server, Part One
- SharePoint 2007 and SQL Server, Part Two
- SharePoint 2007 and SQL Server, Part Three
- Querying Multiple Data Sources from a Single Location (Distributed Queries)
- Importing and Exporting Data for SQL Azure
- Working on Distributed Teams
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
Data Management Objects: Scripting
Last updated Mar 28, 2003.
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.
The full documentation for the SQL Server Object Library can be found here.
The specifics for the scripting method is here.