Tải bản đầy đủ - 0 (trang)
5-18. Transferring Tables Between Databases

5-18. Transferring Tables Between Databases

Tải bản đầy đủ - 0trang

Chapter 5 ■ SQL Server Sources

Figure 5-13.  Configuring an SMOServer connection manager


Click Test Connection.


Click OK to confirm your modifications.


Right-click the connection manager in the Connection Managers tab and click

Rename. Rename the connection manager CarSales_OLEDB.


Repeat Steps 4–6 for the destination server (Adam02\AdamRemote in this example).

Name the connection manager CarSales_Staging_OLEDB.


Add a Transfer Database Objects Task to the Control Flow pane.


Double-click to edit the Transfer Database Objects Task.


Click Objects on the left.


Select CarSales_OLEDB as the source connection.


Select CarSales_Staging_OLEDB as the destination connection.


Select CarSales as the source database.


Select CarSales_Staging as the destination database.


Set the following properties:

















Chapter 5 ■ SQL Server Sources


Expand ObjectsToCopy. Click the Ellipses button to the right.


Select the tables that you wish to copy. The dialog box should look like Figure 5-14.

Figure 5-14.  The SQL Server transfer Objects Task Editor


Click OK to confirm. You return to the Transfer SQL Server Objects Task Editor, which

should look like Figure 5-15.



Chapter 5 ■ SQL Server Sources

Figure 5-15.  Selecting the tables to transfer using the SSIS Transfer SQL Server Objects Task


Click OK to confirm.

You can now run the package. All the selected tables will have transferred.

How It Works

The Transfer SQL Server Objects Task is, in essence, a GUI to SQL Server Management Objects (SMO). This, as

you probably know, is a collection of objects designed to make programming the management of SQL Server

more accessible. One of the things that SMO can do (among so many others) is to drop and create tables, and

to transfer data between tables. In this recipe, we are using the Transfer SQL Server Objects Task to carry out

this operation. As you can see, it allows you to not only select the table(s) to be copied, but can also extend this

operation by copying other elements such as indexes and primary/foreign keys.

You need to be warned that the Transfer SQL Server Objects Task is relatively simplistic in its approach, and

is best suited to transferring tables and data that have few or no dependencies. However, as a tool for copying

entire tables between SQL Server instances, it is unrivalled in its simplicity. A prerequisite for running this task is

to use identical table structures in both the source and destination databases.

When using the Transfer SQL Server Objects Task to load data, you can also request that the task generate

any required tables before it migrates the data. This is as simple as setting the CopySchema option to True. Be

warned, however, that if the tables exist and you set CopySchema to True, then you will get an error when running

the package, as the tables exist already. If you wish, you can set the option DropObjectsFirst to True, as well as

CopySchema to True to replace the structure and data of the existing tables. If the tables already exist in

the destination database and CopySchema is set to False, you will have the option to append—rather than

replace—data by setting ExistingData to Replace.



Chapter 5 ■ SQL Server Sources

The Transfer SQL Server Objects Task is an “all or nothing” solution as far as data migration is concerned. It

will not allow you to subset source data, use source queries, or select only a partial column set. These limitations

can be overcome by using workarounds such as running SELECT...INTO clauses to create temporary tables to

serve as the data source; but then if you are going to do this, you may as well use other solutions to transfer the

data, in my opinion. This task can—as you can see from the available options—do much more than just transfer

data, but a complete analysis of these possibilities is outside the scope of this book.


This chapter contained many ways of getting data from SQL Server sources into SQL Server destinations. Some

of them may seem similar, or to duplicate methods, or simply plain abstruse. To give you a clearer overview,

Table 5-8 shows my take on the various methods, and their advantages and disadvantages.

Table 5-8.  Advantages and Disadvantages of the Methods Used in This Chapter





Easy to use.

Slow (OLEDB).


Easy to use.

Slow (OLEDB).


Easy to use, secure.

Slow (OLEDB).


Incredibly fast.

Needs table metadata.


Extremely fast, fairly cryptic.

Needs to run outside SQL Server—or required

xp_cmdshell rights. Needs table metadata.



File-based only. Requires format file. Needs

table metadata.



Not the fastest method.


Incredibly fast.

File-based only, requires format file.


Fast and automatic.

Complex to debug and troubleshoot.

Scripting out data

Incredibly easy.

Not for large amounts of data.

Backup copy

Incredibly easy.

The whole database or nothing.

Copy and paste

Unbelievably simple.

Only for miniscule amounts of data. Not suited

to a production environment.

When you have to transfer data from one SQL Server instance to another, the only real difficulty is knowing

which of the abundant available options to choose. At least that is how it may seem at first. As I have tried to show

in this chapter, each of the available techniques has its advantages and disadvantages, with some being better

suited to certain circumstances than others are.

So if you are only loading a few records of reference data, then a copy-and-paste may suffice. If you are

moving a few hundred thousand records across a fast network, a linked server might a good solution. If you have

to load many millions of records between servers, then you are probably best advised to think in terms of using

BCP and BULK INSERT. However, it is not for me to mandate solutions. My goal for this chapter was to make you

aware of the many available techniques, along with their salient features. You can choose the most appropriate

technique for your specific requirements and environment.



Chapter 6

Miscellaneous Data Sources

To conclude our tour of source data, we need to look at a handful of data repositories that do not fall under the

more clearly-defined categories of the first five chapters. I suppose that this is another way of saying that the

current chapter is something of a ragbag of diverse data sources, so please accept the rather disjointed nature

of them as we proceed. This does not mean that any of these data sources are unlikely to be used or are not

potentially useful. I am merely stating that they are somewhat more “exotic” and therefore rarer—at least in my


In this chapter, we will look at the following:

Loading data from Analysis Services sources

Storing image and document files in SQL Server

Loading data from Visual FoxPro files

Loading data from dBase files

Returning data from Web Services

Capturing WMI data

Using ODBC connections to connect to miscellaneous data sources

I know that there are many sources of data not included in this book. Perhaps one day you will need to

import Paradox data files or access the wealth of information available in Directory Services, for instance.

Unfortunately, there is simply not space available to cover every possible source of data that can be loaded into

SQL Server, so I selected a core group of sources that I had to handle over the years, and left the others out

of the book.

Sample files used in this chapter are found in the C:\SQL2012DIRecipes\CH06 directory—assuming that

you have downloaded the samples from the book’s companion web site and installed them as described in

Appendix B. This includes a sample SSAS cube that you can load into Analysis Services.

6-1. Importing Data from SQL Server Analysis Services


You want to import data from an SQL Server Analysis Services (SSAS) cube into an SQL Server relational table on

a regular basis.



Chapter 6 ■ Miscellaneous Data Sources


Use SQL Server Integration Services (SSIS) and the Microsoft OLEDB provider to connect to Analysis Services

and import the data in tabular format. This is done as follows:


Create a new Integration Services package. Add a Data Flow task to the Control Flow

pane. Double-click to switch to the Data Flow pane—or click the Data Flow tab,

if you prefer.


Right-click in the Connection Managers tab at the bottom of the screen. Select New

OLEDB Connection. Click New.


Select Native OLEDB\Microsoft OLEDB Provider for Analysis Services 11.0. Enter

the Analysis Services server name — localhost in this example. Choose Integrated

Security. You can then select the cube to which you wish to connect from the Initial

Catalog drop-down list. You should see something like Figure 6-1.

Figure 6-1.  OLEDB connection to an OLAP cube



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

5-18. Transferring Tables Between Databases

Tải bản đầy đủ ngay(0 tr)