SSIS Team Blog : Execute SQL Task

Capture PRINT messages from a stored procedure

mmasson — Thu, 13 Sep 2007 19:28:42 GMT

I recently helped with a customer issue where they had a long running stored procedure which output status messages periodically using PRINT statements. They wanted to capture these statements and output them into the SSIS log. Unfortunately, the Execute SQL Task doesn't support this (it's something we're considering for the future), but it's fairly easy to do through a script task.

Our stored procedure:

   1: CREATE PROCEDURE SPWithPrint

   2: AS

   3: BEGIN

   4:     print 'very important status information...'

   5: END

   6: GO

Our script:

   1: Public Sub Main()

   2:     Dim conn As New SqlConnection("server=(local);Integrated Security=SSPI;database=Test")

3:

   4:     AddHandler conn.InfoMessage, New SqlInfoMessageEventHandler(AddressOf OnInfoMessage)

5:

   6:     conn.Open()

7:

   8:     Dim cmd As New SqlCommand()

   9:     cmd.Connection = conn

  10:     cmd.CommandType = CommandType.StoredProcedure

  11:     cmd.CommandText = "[SPWithPrint]"

12:

  13:     cmd.ExecuteNonQuery()

14:

  15:     conn.Close()

16:

  17:     Dts.TaskResult = Dts.Results.Success

18:

  19: End Sub

20:

  21: Private Sub OnInfoMessage(ByVal sender As Object, ByVal args As System.Data.SqlClient.SqlInfoMessageEventArgs)

  22:     Dim sqlEvent As System.Data.SqlClient.SqlError

  23:     For Each sqlEvent In args.Errors

  24:         Dts.Events.FireInformation(sqlEvent.Number, sqlEvent.Procedure, sqlEvent.Message, "", 0, False)

  25:     Next

  26: End Sub

The print statements return the messages as InfoMessage events, which we catch with our handler and turn into SSIS information events.

When we run the package, we can see the message from the stored procedure in our progress window...

We're looking into adding this functionality to the Execute SQL Task as well, but hopefully this is an acceptable alternative until then.

Why can’t I store my BIGINT result in an Int64 variable?

mmasson — Thu, 19 Apr 2007 07:02:00 GMT

The native providers (OLEDB, ODBC, ADO – ADO.NET doesn't have this problem) in the Execute SQL Task return the BIGINT type as a String, and not an Int64 as you'd expect. Attempting to store the result in an Int64 variable gives you an error along the lines of:

[Execute SQL Task] Error: An error occurred while assigning a value to variable "xxxx": "The type of the value being assigned to variable "xxxx" differs from the current variable type. Variables may not change type during execution. Variable types are strict, except for variables of type Object."

Although this behavior is documented in the books online entry, we don't explain why it was done this way. Being somewhat new to the SSIS development team, I had to do some digging to find out for myself. It turns out that at the time this was implemented, there wasn't cross platform support for the 8-byte integer type (VT_I8/VT_UI8) in VARIANTs -- specifically, on Windows 2000. Now that supporting Win2k is no longer an issue (for Katmai), we're free to change the behavior (while maintaining backwards compatibility for packages that are expecting the value as a string, of course).

Expect this as a likely change in an upcoming release.

Stored procedures with output parameters

mmasson — Thu, 09 Nov 2006 03:07:00 GMT

When executing Stored Procedures with the Execute SQL Task, SSIS passes the statement to the underlying provider without parsing it. While efficient, the different ways of handling the input between the various providers can be a little frustrating. I was working on a couple of issues found in SP1, and realized that when dealing with stored procedures with output parameters, each provider wanted the SQL in a different format.

I'll stick with a simple stored procedure example that returns a single value.

CREATE PROC intoutput
@value INT OUTPUT
AS
SELECT @value = 10

I want my Execute SQL Task to run the stored procedure, and store the result in a package variable (varInt). For different providers, you'll need to change two main fields – the SQL Statement, and the Parameter Name value on the Parameter Mapping page.

OLE DB

SQL Statement: exec intoutput ? output
Parameter Name: 0

You should also set BypassPrepare to True, as the SQL can't be properly parsed if it contains a parameter marker.

1 – OLE DB General

2 – OLE DB Parameter Mapping

ODBC

SQL Statement: {call intoutput (?)}
Parameter Name: 1

The SQL statement for ODBC is very different than the others. You need to use "call" instead of "exec", and wrap the whole thing with curly braces. Also, the parameter numbering starts at 1 instead of 0.

3 - ODBC General

4 - ODBC Parameter Mapping

ADO

SQL Statement: intoutput
Parameter Name:<parameter name>

For ADO, you can use the stored procedure name by itself, and set the IsQueryStoredProcedure attribute to True. For parameter name, you use the name you gave the parameter in the stored procedure (in this case, "value").

5 - ADO General

6 - ADO Parameter Mapping

ADO.NET

SQL Statement: intoutput
Parameter Name:@<parameter name>

ADO.NET is similar to ADO. Set IsQueryStoredProcedure to True, and set your statement to the name of the SP you want to execute. Like ADO, you need to use the name of the parameter in the stored procedure for the Parameter Name column, prefixed with @ (in this case, "@value"). Note: The parameter mapping seems to work without the use of the @ sign, but I'm not sure if that works for all providers.

7 - ADO.NET General

8 - ADO.NET Parameter Mapping

Summary

Running stored procedures with the Execute SQL Task is tricky due to the differences in the way the providers handle the input SQL. The main differences are with the SQL Statement, and the Parameter Name value. The following table summarizes the differences (assumes a stored procedure of name StoredProc with a single output parameter named Param):

Provider	SQL Statement	Parameter Name	Notes
OLE DB	exec StoredProc ? output	0	Set BypassPrepare to True
ODBC	{call StoredProc (?)}	1
ADO	StoredProc	Param	Set IsQueryStoredProcedure to True
ADO.NET	StoredProc	@Param	Set IsQueryStoredProcedure to True

For more info about the Execute SQL Task, you can check out the books online entry, and the nice overview of the task on SQLIS.com.