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 
