Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

Useful information and case studies covering Data Warehousing, Data Modeling, and Business Intelligence

I started my career in IT nearly 10 years ago and have remained influenced and driven by two particular technology initiatives - Business Intelligence and Data Warehousing. Opportunities for partnership, learning, and innovation will continue to present themselves as we strive to meld people, business, and technology. I look forward to these opportunities as I am fulfilled by my membership to a scientific community that is driven by the development and execution of technology solutions that enhance the way we live and conduct business.

SSIS How-To: Reuse Existing Connection Manager to Execute SQL in Script Task

There’s a myriad of examples out there on how to execute a sql task via OLEDB connections and C# in a SSIS Script Task.   However, I have yet to find a best practice solution that reuses an existing connection manager to properly establish, execute the SQL script (either dynamic or static), and dispose of an OLEDB connection.

Below is the base code that follows Microsoft’s best practice guidelines to execute dynamic SQL via C# against an existing SSIS connection manager.

1. In the script task, ensure that the following library is included:

‘using System.Data.OleDb;’


.
.
.
.

2. Import the following DLL to allow C# to import the connection string from the connection manager established in the package – Microsoft.SqlServedllSearchr.DTSRuntimeWrap.dll:

To import a missing DLL:
-If the Project Explorer pane is not visible in the Script Task script then click VIEW >> Project Explorer
-As the pane is now visible, right click REFERENCES >> ADD REFERENCE >> choose BROWSE and find the DLL

Note: On my Visual Studio installation, the DLL was imported from the following location – C:\Program Files\Common Files\microsoft shared\VSTA\Pipeline\AddInViews\Microsoft.SqlServedllSearchr.DTSRuntimeWrap.dll

After the DLL has been imported it can be viewed in the Project Explorer pane, as displayed below.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

3.  Here is a complete example as seen in public void Main():

VariableDispenser variableDispenser =this.Dts.VariableDispenser;
Variables lockedVariables =null;
variableDispenser.LockForRead(“User::VAR_CutoffDate”);
variableDispenser.GetVariables(ref lockedVariables);

string cutOffDate = lockedVariables["VAR_CutoffDate"].Value.ToString();
string sqlScript = “SELECT “ + cutOffDate;

try
{

ConnectionManager cm = Dts.Connections["Minerva"];       Microsoft.SqlServer.Dts.Runtime.Wrapper.IDTSConnectionManagerDatabaseParameters100 cmParams = cm.InnerObject as Microsoft.SqlServer.Dts.Runtime.Wrapper.IDTSConnectionManagerDatabaseParameters100;

    using (OleDbConnection conn = cmParams.GetConnectionForSchema() as OleDbConnection)
{
OleDbCommand command =new OleDbCommand(sqlScript, conn);
command.ExecuteNonQuery();
}

}

 catch (Exception e)
{
//event handling
    //MessageBox.Show(e.ToString());
 }

if (lockedVariables.Locked) { lockedVariables.Unlock(); }
Dts.TaskResult = (int)ScriptResults.Success;

Note: We’ve all been guilty of not accounting for common exceptions in C# logic, leaving the .Close() or .Dispose() function never to be called.

The line from above - ‘using (OleDbConnection conn = cmParams.GetConnectionForSchema() as OleDbConnection)’  follows Microsoft best practice of incorporating the the ‘using()’ function to automatically dispose of the OleDbConnection object (and any other disposable object for that matter) as opposed to .Close() or .Dispose() even if an exception is thrown.

So go with  ‘using’, it’s less problematic, saves us a few lines of coding, and leaving tools hanging isn’t as hilarious as it is on the street :)


Comments

Leave a comment on the original post [saldeloera.wordpress.com, opens in a new window]

Loading comments...