http://www.sqlservercentral.com/articles/Testing/66553/

Look! An image….

0: Strip sensitive information.
1: Sensitive information is encrypted by using local user credentials.
2: Sensitive information is encrypted by using the required password.
3: The package is encrypted by using the required password.
4: The package is encrypted by using local user credentials.
5: The package uses SQL Server storage encryption.

SQL Server Books On Line: Creating a Deployment Utility

Technet: Setting the Protection Level of Packages

KB906562: How to use the dtutil utility (Dtutil.exe) to set the protection level of a batch of SQL Server Integration Services (SSIS) packages in SQL Server 2005

Luckily, this led me to discover a new favorite utility in Visual Studio the rest of the world already knew about - Find and Replace. From the VS.NET menu: Edit >> Find and Replace >> Find in Files (or [Ctrl]+[Shift]+F for keyboard jockeys)

you can launch “Find and Replace”

which made me happy enough for accurately searching the .dtsConfig files (as opposed to Windows Explorer’s Search…) But what my new favorite VS.NET feature, Folder Sets. By clicking the browse ellipses next to the “Look in”drop down, I can set the search folders with the “Choose Search Folders” dialog:

where I can set (and save) a batch of folders I want the Find and Replace utility to search. So simple, I see myself using this a lot in the future.

“The IT industry currently consumes 1.5 percent of the energy in the United States, and that is expected to grow to 3 percent by 2010, making the industry the second largest industrial consumer of power, behind heavy manufacturing.”

Here is how I log dynamically generated SQL statements, built using the Script component within SSIS. This is based on an example I saw online somewhere - but I can no longer remember where to give proper credit.

Write a Script component that contains code similar to this:

Public Sub Main()
Dim DynamicSQLStatement As String
Dim emptyBytes(0) As Byte
Try
' Build Dynamic SQL Statement
DynamicSQLStatement = "SELECT MyColumn FROM MyTable"
' Generate Log Statement
Dts.Log("Dynamic SQL Generated: " & DynamicSQLStatement, 0, emptyBytes)
' Return the dyanmic SQL for user in OLE Source component
Dts.Variables("DynamicSQLStatement").Value = DynamicSQLStatement
Dts.TaskResult = Dts.Results.Success
Catch ex As Exception
Dts.TaskResult = Dts.Results.Failure
End Try
End Sub

Enable the “ScriptTaskLogEntry” for this component. Note: I already have logging enable at the package level, but I override it for the script component to gain access to the “Script Task Log Entry”. (click image to enlarge)

In this case, I have SQL Server logging configured, so the log entry appears in the table dbo.sysdtslog90.

This is incorporated into a larger logging & auditing system (largely based on the Kimball method presented by Joy Mundy here), so that I can trace what SQL was used by a particular ETL batch.

I am using Visual Studio Team Suite with the Database Professionals add on (”Data Dude”) - with SR1 installed. However, when I build the database project, I am not getting the expected results in the resulting omnibus .SQL script. As a result, I have to build the project, then manually edit the .SQL file, and deploy the script from the command line using SQLCMD.EXE — all of which is preventing me from automatically building & deploying with a single-click from the VS IDE (which I want to do).

Here are how I’ve set up the variables in my database project (click the image to enlarge):

Building the project creates a script with no “setvar: ” statements for the variables I’ve added to the project:

SET ARITHABORT, CONCAT_NULL_YIELDS_NULL, ANSI_NULLS, ANSI_PADDING, ANSI_WARNINGS, QUOTED_IDENTIFIER ON
SET NUMERIC_ROUNDABORT OFF
GO
:setvar DatabaseName "SIDW_LOCALDEV"
:setvar PrimaryFilePhysicalName "F:\SQL2005 DATA\SIDW_LOCALDEV.mdf"
:setvar PrimaryLogFilePhysicalName "F:\SQL2005 DATA\SIDW_LOCALDEV_log.ldf"

I expected (but did not see) the following lines as well:

:setvar SQLUserDWETL "DevDWETL"
:setvar SQLUserDWAudit "DevDWAudit"
:setvar SQLUserDWReader "DevDWReader"


These values are used in other scripts, such as this line in the “Post-Deployment” script “Permissions.sql”

GRANT SELECT ON OBJECT::[DW].[vDailyCalendar_dim] TO [$(SQLUserDWReader)]
GO

Are my expectations out of line, or should the “Build” command for the database project output a SQL file that contains the setvar statements?

Note - I’ve created a thread on microsoft’s forums to help track down a resolution. If one surfaces, I’ll be sure to note it here.

UPDATED - Turns out my expectations were incorrect. See the thread for the details. Basically if you deploy from the IDE, DataDude will pass the variable values to the deployment and you’re good to go. If you want to use the SQL script generated by a build, you’ll have to provide them there (basically doing what Data Dude does within the IDE). Many thanks to Gert Drapes for the prompt response.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=263780&SiteID=1