Hands-On Microsoft SQL Server 2008 Integration Services part 65 docx

618 Hands-On Microsoft SQL Server 2008 Integration Services
Exercise (Use the Package Migration Wizard)
In the first part of this Hands-on, you will create a new project and run the Package
Migration Wizard by right clicking the SSIS Packages node. This will not only migrate
the package but will add it in the project as well.
1. Start BIDS and create a new Integration Services project with the following details:
Name Migrating Importing Contacts
Location C:\SSIS\Projects
2. When BIDS loads the blank project, go to the Solution Explorer window, right-
click the SSIS Packages node, and choose Migrate DTS 2000 Package from the
context menu (see Figure 14-13).
3. This will invoke the Package Migration Wizard, and you will see the first screen
of this wizard. Click Next to move on.
4. The Choose Source Location screen allows you to select the location where your
package is stored. Click the down arrow in the Source field to see the list of
source locations. The Package Migration Wizard can read DTS 2000 packages
stored in Microsoft SQL Server or in a structured storage file. As mentioned,
SQL Server 2005 does not support Meta Data services (also called the repository).
If your DTS 2000 package is stored in Meta Data services, you may prefer to save
those packages to the locations supported by the Package Migration Wizard. In
case you cannot do that, the Package Migration Wizard provides a way to read
packages from Meta Data services when SQL Server 2000, SQL Server 2000
tools, or the repository redistributable files are installed on the local computer.
For this exercise, select Structured Storage File in the Source field.
Figure 14-13 Starting the Package Migration Wizard
Chapter 14: Migrating to Integration Services 2008 619
5. Specify C:\SSIS\RawFiles\Importing Contacts.dts in the File Name field as
shown in Figure 14-14. Alternatively, you can choose this file by clicking Browse.
Click Next to move on.
6. In the Choose Destination Location screen, specify the folder where you want to
save the migrated package. The migrated package is created as a new DTSX file,

and your DTS 2000 package is left as is without any changes. In the Folder Name
field, specify C:\SSIS\Projects\Migrating Importing Contacts as the folder where
you want to save the migrated package (see Figure 14-15). You can also click
Browse to choose this folder, which also provides you an opportunity to create a
new folder if you need to. Click Next.
7. As a structured storage file can have multiple packages and package versions, you
can select the packages and their versions you want to migrate in the List Packages
screen. You can also modify the name of the migrated package by editing the
Destination Package field for the selected package. Select the Importing Contacts
package and change the Destination Package to Importing Contacts (Migrated)
by directly typing it into the field (Figure 14-16). Click Next.
Figure 14-14 Specifying the DTS 2000 package location
620 Hands-On Microsoft SQL Server 2008 Integration Services
8. In the Specify A Log File screen, click Browse and specify Migrating Importing
Contacts.Log in the File Name field after selecting the C:\SSIS\RawFiles folder
and click Save. Select Yes to create this file. Then click Next.
9. The Complete The Wizard screen shows you summary information for all the
options that you have selected in the previous screens. Note that this screen also
tells you the number of packages that will be migrated and the number of packages
that will not be migrated. Review the information and click Finish when ready.
10. You will see activities occurring while the package is being migrated, component by
component in the Migrating The Packages screen. You can interrupt this process
by clicking Stop if necessary. Once the package is migrated completely, you will
see a success status for the package. At this stage you can see the report by clicking
Report. Once you’re happy, click Close to close the Package Migration Wizard.
11. As the Package Migration Wizard is closed, you will notice that a package by the
name Importing Contacts (Migrated).dtsx has been added in the SSIS Packages
Figure 14-15 Specifying a destination folder for the migrated package
Chapter 14: Migrating to Integration Services 2008 621
node in the Solution Explorer window. You can delete the blank package

Package.dtsx, as it is not required in this exercise.
12. Explore to the C:\SSIS\RawFiles folder and open the Migrating Importing
Contacts.Log file using Notepad. This shows you details of how the migration
progressed.
Exercise (Execute the Migrated Package)
In this final part, you will execute the migrated package.
13. Double-click the Importing Contacts (Migrated).dtsx package to open it. You
will see a Data Flow task named DTSTask_DTSDataPumpTask_1 on the
Control Flow Designer surface. Notice that this is the DTS 2000 data pump task
name. Also, two connection managers were added: the OLE DB Connection
Manager for connecting to the Campaign database, and a Flat File Connection
Manager for connecting to the Contacts.txt file. Double-click the Data Flow task
to open the Data Flow panel.
Figure 14-16 Selecting DTS 2000 packages that you want to migrate
622 Hands-On Microsoft SQL Server 2008 Integration Services
14. As the DTS 2000 package was quite simple, you will see a flat file source and
an OLE DB destination adapters connected by a data flow path with a data
conversion task in between in the Data Flow Designer surface. Press 
5 to execute
the package and check that it has been migrated successfully.
15. Press -5 to stop debugging the package. Go to the Data Flow tab and
double-click the OLE DB Destination to open the editor. Review the settings in
the Connection Manager page. Go to the Mappings page and note that though
the input column names do not match with the destination columns, they have
been mapped correctly. When you’re done, click OK to close the editor.
Review
You’ve used the Package Migration Wizard to migrate a DTS 2000 package to Integration
Services. You selected a DTS 2000 package stored on the file system in a structured
storage file and saved the destination package in the DTSX format on the file system.
In the end, you observed that though the package was migrated successfully and no

error was reported, the settings do seem in need of tuning. The point to be noted is
that the Package Migration Wizard can migrate most of the components successfully,
yet it needs to be tested out and the migrated package might need configurations.
Upgrading Integration Services 2005
If you are facing the task to upgrade a previous version of Integration Services, you will
find this section useful as you will learn about various options available to you when
upgrading from Integration Services 2005. Depending upon how the server is currently
configured and what you want to achieve, you will choose one of the various options
available to you that are explained next.
Before we go ahead and look at pros and cons of each approach, let us understand
what key changes have been implemented in SQL Server 2008 from the point of view
of Integration Services 2008. If you save your packages to SQL Server, they get stored
into the MSDB database. However, they are stored in different tables, depending on
which version of the SQL Server or Integration Services you use. As you know, SQL
Server 2000 uses the sysdtspackages table to store DTS packages and Integration
Services 2005 uses the sysdtspackages90 table to store SSIS packages in the SQL Server
2005 MSDB database. With the SQL Server 2008 release, the word “dts” has been
replaced in these tables with the more relevant word “ssis” and the table Integration
Services 2008 uses to store packages is named as sysssispackages. Not only the storage
table but other relevant tables used by Integration Services have undergone this change
too—e.g., sysssispackagefolders and sysssislog tables. Understanding this difference
alone will answer most of your questions on differences in behavior between the two
versions of Integration Services.
Chapter 14: Migrating to Integration Services 2008 623
The other key difference is made in BIDS, which uses Microsoft Visual Studio
Tools for Applications (VSTA), replacing the Microsoft Visual Studio for Applications
(VSA) environment. This will mean that all your scripts you have developed in SSIS
2005 need to be upgraded to the VSTA environment. You do not need to worry
here, as VSTA converts VSA scripts for you. Having understood these changes, let us
explore the options described.

Same-Server Installation
In this case both the SQL Server Database Engine and Integration Services are running
on the same server currently and you wish to upgrade them. In this case you might choose
from one of the following two options:
Running side-by-side
c
Upgrading both SQL Server and Integration Services c
Running Side-by-Side
First of all, the good news is that Integration Services 2008 can coexist with Integration
Services 2005 as it does with Data Transformation Services. If you install Integration
Services 2008 side-by-side with its 2005 predecessor, you can run both versions of
packages with their respective development environments. Considering the changes in
Integration Services storage tables and the changes in BIDS as explained earlier, the
following issues will come up:
BIDS 2005 can maintain and develop SSIS 2005 packages, while BIDS 2008 can
c
maintain and develop SSIS 2008 packages.
BIDS 2008 can open and load SSIS 2005 packages, while BIDS 2005 cannot
c
open SSIS 2008 packages. When opening an SSIS 2005 package in BIDS 2008,
the SSIS 2005 package gets converted at loading stage into SSIS 2008 format.
BIDS then works on this package format, and once this loaded and converted
package is saved, it can’t be opened using BIDS 2005.
Much as described in the preceding point, when you try to run an SSIS 2005
c
package using the SSIS 2008 dtexec utility, the utility temporarily converts the
package into SSIS 2008 version before running it. is happens only in memory
and the original version is not changed.
Due to differences in storage locations, Integration Services cannot use different c
versions of SQL Server to store packages, as the tables and metadata won’t exist.

at is, Integration Services 2008 needs SQL Server 2008 and Integration
624 Hands-On Microsoft SQL Server 2008 Integration Services
Services 2005 needs SQL Server 2005 to store packages. is also means that you
cannot connect to an SSIS 2005 instance from SSMS 2008. However, you can
modify the configuration file so that you can manage SSIS 2005 packages from
SSMS 2008. is also enables you to import packages into SQL Server 2008 from
an instance of SSIS 2005, but not the other way around: using SQL Server 2005
Management Studio doesn’t allow you to manage or connect to a higher version
of Integration Services, nor does it allow you to import or export packages to
SSIS 2008.
Upgrading Both SQL Server and Integration Services
Your next option is to upgrade both SQL Server and Integration Services, especially
if they exist on the same server. As discussed earlier in the chapter, you can use the
Upgrade Advisor to find out any issues with the upgrade and can fix them before you
begin the upgrading process. When you run the upgrade process and choose to upgrade
both SQL Server 2005 and Integration Services 2005 to their respective 2008 releases,
the upgrade process performs a series of tasks that are important to understand.
e upgrade process replaces the SSIS 2005 files with SSIS 2008 files and
c
configures Integration Services to point to the new instance of SQL Server 2008.
It creates new metadata, tables, and stored procedures for Integration Services in
c
the MSDB database, removing the old msdb.sysdts*90 system tables and the system
stored procedures used by SSIS 2005. e new tables, named as msdb.sysssis*, contain
the required metadata for SSIS 2008.
It creates three new fixed database-level roles: db_ssisadmin, db_ssisltduser, and c
db_ssisoperator for access control to SSIS packages. e SSIS 2005 roles of
db_dtsadmin, db_dtsltduser, and db_dtsoperator are added as members to the
corresponding new roles.
e most important task it does from the user perspective is to move SSIS c

packages from old store locations to new store locations. Bear in mind that it
can do this only for the locations it is aware of. So, it moves packages from the
sysdtspackages90 system table to the sysssispackages system table for the packages
that are stored in the MSDB database. And it moves packages stored in SSIS
2005 default SSIS package store, that is, the …\SQL Server\90 folder, to the
new default location under …\SQL Server\100. Along with moving packages, it
also moves the folder structure you have created in SSIS 2005 by moving folder
metadata from the sysdtsfolders90 system table to the sysssispackagefolders
system table. All other storage locations used to store SSIS 2005 packages remain
as-is and no change happens there, as the upgrade process is not aware of them.
Chapter 14: Migrating to Integration Services 2008 625
While it moves packages to new storage locations, it does not migrate them to c
2008 format. You will need to migrate them separately using the SSIS Package
Upgrade Wizard. e sysssispackages table shows values in the packageformat
column to indicate the version of the package. e packages that are still in the
SSIS 2005 version will have a value of 2, whereas the packages that are in SSIS
2008 will have a value of 3. You can use the packageformat column to identify the
current version of the packages when looking to upgrade existing packages.
Last, the SQL Server Agent jobs that use dtexec utility directly will not run due
c
to a change in the path of the dtexec utility in the 2008 release. You will need to
modify these jobs yourself.
Different Server Installation
In this installation, you have a SQL Server database engine installed on one computer
while the Integration Services package that connects to this database instance is
installed on another computer. You might choose one of the following two options in
such a scenario:
Upgrading SQL Server Database Engine only
c
Upgrading Integration Services only c

Upgrading SQL Server Database Engine Only
In this scenario you upgrade only the SQL Server database engine that is used by
Integration Services to store packages. The Integration Services process could be on a
different server and remains on 2005 version. This shows your intention to keep using
SSIS 2005 without upgrading packages even after an upgrade of SQL Server. Here are
the limitations that apply in this case:
You can still use BIDS 2005 to develop and modify existing Integration Services
c
packages that are stored in the file system.
e system tables used by Integration Services in the MSDB database get
c
migrated to 2008 format as has been discussed in the preceding section, and the
SSIS 2005 packages are moved to the new system table. is change renders
Integration Services 2005 unable to open the packages stored in SQL Server.
Actually, not only Integration Services but the other SQL Server 2005 tools
on other computers, such as BIDS, SQL Server Management Studio and SQL
Server 2005 Agent Jobs, cannot discover the packages on the upgraded instance
of the database engine. at is, the packages are not available on the upgraded
626 Hands-On Microsoft SQL Server 2008 Integration Services
instance of SQL Server from the perspective of the SSIS 2005 toolset. You should
keep a copy of packages on the file system before upgrading the database engine
if you intend to keep using SSIS 2005 even after an upgrade of the SQL Server
database engine.
Upgrading Integration Services Only
In this scenario you upgrade only the Integration Services while the SQL Server
database engine that is used to store packages is on another computer and continues
to be the 2005 version. You intend to upgrade packages after the upgrade, though the
SQL Server is not upgraded. Here are the limitations that apply in this case:
e packages stored in the file system are available to Integration Services 2008
c

and can be easily upgraded using the SSIS Package Upgrade Wizard. However,
the upgraded packages or the new SSIS 2008 packages cannot be saved to SQL
Server 2005, as BIDS 2008 looks for the 2008 versions of system tables in the
MSDB database.
e packages stored in SQL Server 2005 cannot be accessed by BIDS 2008 due
c
to different system tables. However, these packages can still be executed by SQL
Server Agent jobs that run on SQL Server 2005, as no change has happened on
the SQL Server.
Later, if you want to upgrade the packages that are stored in SQL Server 2005, c
you will have to export them to a file system so as to enable BIDS 2008 to access
them.
Upgrading SSIS 2005 Packages
By now you understand that the upgrade process moves the existing SSIS 2005 packages
to new system tables or to the new SSIS Package Store, but does not upgrade them to
2008 format. You will have to manually upgrade these packages. Following are the tools
that you can use and the consideration you need to be aware of while upgrading SSIS
2005 packages to SSIS 2008 format.
If you open an SSIS 2005 solution or project in BIDS 2008, the Visual Studio
c
Conversion Wizard starts automatically (Figure 14-17) and converts the solution
or the project created in the previous version to the current version. is is in-
place conversion, so you should take a backup or keep a copy in another location
before proceeding further. If the solution or project is under source control, it
Chapter 14: Migrating to Integration Services 2008 627
will automatically be checked out during the conversion. Once the Visual Studio
conversion completes, the SSIS Package Upgrade Wizard starts automatically.
You can use the SSIS Package Upgrade Wizard to upgrade one or many SSIS
c
2005 packages (see Figure 14-18) together to SSIS 2008 format. is tool is

installed when you install Integration Services 2008 and is available only in
Standard, Enterprise, and Developer Editions of SQL Server. is wizard can also
be started manually from one of the following places:
By right-clicking the SSIS Packages node in the Solution Explorer and
c
selecting the Upgrade All Packages option
While connected to Integration Services in SSMS, by expanding the Stored
c
Packages node and then right-clicking the File System or MSDB node and
selecting the Upgrade Packages option
From Installation Center | Tools | Upgrade Integration Services packages
c
By running the SSISUpgrade.exe file from the command prompt after going c
to the C:\Program Files\Microsoft SQL Server\100\DTS\Binn folder
Figure 14-17 Visual Studio Conversion Wizard