Calling an SSIS package from a SQL Server Agent job step

If possible, always use Operating system (CmdExec) SQL Server Agent job step and DTExec.exe utility to call an SSIS package from a SQL Server Agent job step. The gives you much more verbose output information than SSIS Package step and makes troubleshooting much easier.

Just compare this:

Executed as user: DOMAIN1\sqlagent2005.
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.1399.06 for 64-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 10:12:30 AM
Error: 2006-10-27 10:12:30.83
Code: 0xC0014060
Source: {9D739ECB-C57C-4A4D-9DFE-80183F7B7002}
Description: Failed to decrypt a package that is encrypted
with a user key. You may not be the user who encrypted this
package, or you are not using the same machine that was
used to save the package.
End Error
Could not load package "C:\Program Files\Microsoft SQL Server
\90\DTS\Packages\Package1\Package1.dtsx" because of error
Description: Failed to remove package protection with error
0x8009000B "Key not valid for use in specified state.". This
occurs in the CPackage::LoadFromXML method.
Source: {9D739ECB-C57C-4A4D-9DFE-80183F7B7002}
Started: 10:12:30 AM
Finished: 10:12:30 AM
Elapsed: 0.438 seconds.
Process Exit Code 5.
The step failed.

and this:

Executed as user: DOMAIN1\Administrator.
The package could not be loaded.
The step failed.


Also, check the comment below for yet another reason that proves the point I am making here.


SSIS Back Up Database task - yet another annoying SQL Server 2005 'feature'

If you are using the Back Up Database tasks in your SSIS packages, you should be aware that every time you click on the Databases drop-down-list-like thing and then you click OK to close it, the folder location in the Folder textbox is automatically set to the default backup location. So if you are using another location to store your backups, you have enter it every time you change or even view the list of backed up databases.


SSIS package configuration files

SSIS package may ignore a configuration file (the dtsConfig file) and use variable values stored in the package (the dtsx file), if the configuration file contains one or more special Polish characters (even if there are used only in comments - <!-- the comments go here -->).

I have no idea when or why it happens, but I have a package that worked fine, then started to behave strangely and then it all came back to normal, when I removed special Polish characters from the comments in the configuration file. The bug is reproducible.


HOWTO: Format nicely an XML document (beautifying XML)

From time to time I have an XML file that needs to be formatted nicely. If the file is small, I usually do it manually.

However, lately I was working with SSIS. I created a package with an XML configuration file. And it came out that Visual Studio 'thinks' it is a great idea to put all content of the file in one line. Well, it is not, but I have already got used to such bugs in SQL Server 2005.

The configuration file was totally unreadable, but I remembered that I had already had such problem in the past. After some searching, I downloaded XMLStarlet (that I had also used last time).

All you have to do to format nicely an XML file is to type:

xml.exe format ugly_formatted.xml > nicely_formatted.xml

Of course, XMLStarlet can do much more.