SSIS Team Blog : SMO

Transfering a couple of tables at a time

mmasson — Wed, 31 Oct 2007 21:04:00 GMT

I missed some of the comments to my post about creating your own Transfer SQL Objects Task with a script task, so I thought I'd post the answer here incase people miss my answer.

You can use the ObjectList property of the Transfer object to specify which database objects you want to transfer. To transfer only certain tables from a database, you'd set CopyAllTables to false, and then add Table objects to the object list.

Note, when accessing the Tables collection of the Database object, you can specify the table by index or by name. You can also use an additional schema name parameter if there are duplicate table names in separate schemas.

Database sourceDB = new Database("source");

Transfer xfer = new Transfer(sourceDB);

xfer.CopyAllTables = false;

[...]

xfer.ObjectList.Add( sourceDB.Tables["table1"] );

xfer.ObjectList.Add( sourceDB.Tables["table2", "schema1"] );

xfer.ObjectList.Add( sourceDB.Tables["table2", "schema2"] );

xfer.ObjectList.Add( sourceDB.Tables["table3"] );

Roll your own Transfer SQL Server Objects task

mmasson — Thu, 19 Apr 2007 02:08:00 GMT

Awhile back we went through a lot of customer feedback logged through the Connect site concerning the Transfer SQL Server Objects task. Some of these turned out to be bugs, but a lot of the reported issues stemmed from usability problems with the task itself. There's actually not that much to the task on the SSIS end – it uses the SQL Server Management Objects (SMO) API to do the bulk of the work. Anyone familiar with the SMO Transfer object will notice the similarities in the task's UI. We end up exposing the majority of the Transfer object's members as properties, which leads to most of the reported problems with the task; it's complicated, and options sometimes conflict with each other.

It's always a challenge to get the right balance of usability and functionality, and we're hoping to address the problems with this task in a future release (suggestions are always welcome). In the mean time, you can always "roll your own" version of task using the SMO API directly through a script task.

First you'll need to add references to the three SMO assemblies (found under Microsoft SQL Server\90\SDK\Assemblies):

Microsoft.SqlServer.ConnectionInfo
Microsoft.SqlServer.Smo
Microsoft.SqlServer.SmoEnum

Import the SMO namespaces in your code:

Imports Microsoft.SqlServer.Management.Smo

Imports Microsoft.SqlServer.Management.Common

The following code was adapted from one of the samples on MSDN. It creates a new database on your local server, and sets up a Transfer object to copy across all tables, dependencies, and data from the AdventureWorks database.

Public Sub Main()

Dim dbSourceName As String = "AdventureWorks"

Dim dbDestName As String = dbSourceName + "Copy"

'Connect to the local, default instance of SQL Server.

Dim srv As Server

srv = New Server

'Reference the source database

Dim db As Database

db = srv.Databases(dbSourceName)

'Create a new database that is to be destination database.

Dim dbCopy As Database

dbCopy = New Database(srv, dbDestName)

dbCopy.Create()

'Define a Transfer object and set the required options.

Dim xfr As Transfer

xfr = New Transfer(db)

xfr.CopyAllTables = True

xfr.Options.WithDependencies = True

xfr.Options.ContinueScriptingOnError = True

xfr.DestinationDatabase = dbCopy.Name

xfr.DestinationServer = srv.Name

xfr.DestinationLoginSecure = True

xfr.CopySchema = True

'Include data

xfr.CopyData = True

'Execute the transfer

xfr.TransferData()

Dts.TaskResult = Dts.Results.Success

End Sub

Another useful method of the Transfer object is ScriptTransfer() – it returns the T-SQL script of what you've configured your Transfer object to do. You can dump this to debug any issues you run into, and to figure out exactly what SMO is doing.

Interestingly, SMO actually uses SSIS internally to do its data transfer. It creates a couple of temporary packages on-the-fly, and runs behind the scenes. (It's possible to capture the scripts and packages if you set break points in the right place – send me an email or leave comments if you're interested in how to do this).

DANGER! DropObjectsFirst and CopyAllObjects on the same server

mmasson — Thu, 01 Mar 2007 06:36:00 GMT

A post in the forums had me try out what turned to be a dangerous combination of flags in the Transfer SQL Objects task. The user said they were no longer able to access their database after running their package, and I was curious as to why this would be... It turned out to be a logic problem with the DropObjectsFirst and CopyAllObjects flags.

CopyAllObjects will copy all objects (go figure) associated with the Source Database. This includes all Login objects. In this case, the user was copying his database to the same server, with a new table name. Since DropObjectsFirst was set to True, the Login objects were flagged to be copied, and we end up deleting the logins before doing the copy! This put the server in a bad state of course, which not only causes the task to fail, but prevents anyone from logging into the server from that point on.

I did a little research, and it turns out this is an issue that is scheduled to be fixed in Katmai. It's not a bug, per se – it's more of "unintended consequence" that isn't very obvious (as the user who wrote the post said, why does SSIS drop my logins when I just want to copy one database!)

The most likely fix would be to detect that the source and destination servers are the same, and report a validation error that the logins (or other server objects) are set to be dropped. This will hopefully prevent people from nuking their servers in the future.