Sql-server – SSI package execution failed

Using WITH RESULT SETS to explicitly define the metadata will allow SSIS to skip the sp_describe_first_result_set step and use the metadata that you define. The upside is that you can use this to get SSIS to execute SQL that contains a temporary table (for me, that performance helped a lot); the downside is, you have to manually maintain and update this if anything changes.

Query sample (stored procedure:)

    EXEC ('dbo.MyStoredProcedure')
    WITH RESULT SETS
      (
        (
            MyIntegerColumn INT NOT NULL,
            MyTextColumn VARCHAR(50) NULL,
            MyOtherColumn BIT NULL
        )
      )

Query sample (simple SQL:)

EXEC ('
    CREATE TABLE #a 
      (
        MyIntegerColumn INT NOT NULL,
        MyTextColumn VARCHAR(50) NULL,
        MyOtherColumn BIT NULL
      ) 
    INSERT INTO #a 
      (
        MyIntegerColumn,
        MyTextColumn,
        MyOtherColumn
      )
    SELECT 
        1 AS MyIntegerColumn,
        ''x'' AS MyTextColumn,
        0 AS MyOtherColumn

    SELECT MyIntegerColumn, MyTextColumn, MyOtherColumn
    FROM #a')

WITH RESULT SETS
    (
        (
            MyIntegerColumn INT NOT NULL
           ,MyTextColumn VARCHAR(50) NULL
           ,MyOtherColumn BIT NULL
        )
    )

I ran into this issue after releasing a new SSIS project to the production environment.

At first, I was able to validate the package with success, but when I tried to execute the package, I got the DTS_E_OLEDBERROR. Error code: 0x80004005. message.

I tried to validate the package with the servername and password variables set to sensitive, but in this case the validation failed as well.

After setting the environment variables back to non-sensitive again and inserting the environment variable values, I was able to validate and execute the package.

To me it seems like in some cases the metadata in the SSISDB gets corrupted, but unfortunately I've not been able to point down the source of this issue.

I hope this will help someone. I've went through a lot of debug scenarios before I ended up with this (rather unsatisfying) solution.