The SQL Error Log does not help much at all. Here’s what’s in the SQL Error log:
2011-05-06 09:06:17.28 Logon Error: 18456, Severity: 14, State: 38.
2011-05-06 09:06:17.28 Logon Login failed for user ‘DOMAIN\ssrs.service’. Reason: Failed to open the explicitly specified database. [CLIENT: 192.168.0.147]

The Windows Application log is not much help either.
Login failed for user ‘DOMAIN\ssrs.service’. Reason: Failed to open the explicitly specified database. [CLIENT: 192.168.0.147]

In other words, useless for troubleshooting. The way to obtain the database name the client is trying to connect to is to use SQL Server Profiler.

To set up SQL Server Profiler, connect to the SQL instance where the error is occuring and then track the following events:
Errors and Warnings: User Error Message
Security Audit: Audit Login Failed

For these two events, make sure you capture at least the following columns: ApplicationName, HostName, LoginName, SPID (required), StartTime, TextData (where the message text will be), Severity, State, ClientProcessID, and Error.

Then run the trace. You’ll see the following data under the “User Error Message” event when the login failure occurs:
Cannot open database “DatabaseName” requested by the login. The login failed.
For the “Audit Login Failed” event you’ll see the following data:
Login failed for user ‘BLUENE\ssrs.service’. Reason: Failed to open the explicitly specified database. [CLIENT: 192.168.0.147]

Using this information (and the rest of the info in the other columns you selected), you should be able to go to the source and identify which process is trying to connect to the specified database and take appropriate action.

If you’re interested in the other states that error 18456 can generate, please visit fellow MVP Aaron Bertrand’s page on this topic for a very nice listing.

Attached is the SQL Profiler Trace Template for SQL 2008 instances if you want to import it instead of manually configuring SQL Profiler. To import the template, in SQL Server Profiler, go to File->Templates and select Import…

SQL_Login_Failures_Profiler_Template.tdf (860 bytes)

First, setup four package level variables:
FilePath – string
SSISFolderFilePath – string
SSISFolderName – string
SSISFolders – object

FilePath should be set to the location where you want to store the packages. Include the trailing slash, and ensure that the location exists.
SSISFolderFilePath should be set to evaluate an expression (EvaluateAsExpression = TRUE), and its expression should be:
@[User::FilePath] + @[User::SSISFolderName]

Then create a connection manager object that points to your MSDB database where you want to extract from. If you want this to be dynamic, perhaps to archive ALL SSIS packages in your company, then this could be made a dynamic connection manager object (by using expressions) and you iterate over each server. For now, we’re only going to use one server.

Once these are setup, the rest is point and click, pretty much. Add an Execute SQL Task to the control flow, and configure it so that it returns a full resultset. See below.

The query for the Execute SQL Task is:

SELECT foldername
  FROM dbo.sysssispackagefolders folders
 WHERE EXISTS (SELECT NULL
                 FROM dbo.sysssispackages pkg
                WHERE pkg.folderid = folders.folderid)

*Note – the above SQL only assumes a flat directory structure. If you have subdirectories in MSDB, you can use a recursive CTE to create a hierarchy resultset.

With the Execute SQL Task set up, you’ll have to shred the results using a Foreach Loop Container. Inside the Foreach Loop Container, we will want to use a File System Task to create directories for our packages if they do not already exist. The configuration for that is below:

Next, we have to create a data flow and attach it to the Foreach Loop Container. The full control flow should resemble the next screenshot.

In the data flow, we have three components – OLE DB Source, Derived Column, and the Export Column transformation. Connect the OLE DB source to your connection manager object, and use the following query against MSDB:

SELECT folder.foldername,
       pkg.name,
       pkg.packagedata
  FROM dbo.sysssispackages pkg
  JOIN dbo.sysssispackagefolders folder
    ON pkg.folderid = folder.folderid

Then, configure the Derived Column component so that it creates one new column, FullFilePath. The following is the expression to use:

(DT_WSTR,500)(@[User::FilePath] + foldername + "\\" + name + ".dtsx")

Then configure the Export Column transformation as the following screenshot illustrates:

The final data flow should look like the following:

The only thing left to do is execute the package. Navigate to the location defined by the FilePath package variable and you should see a directory structure resembling that in MSDB with all of the SSIS packages saved.

If you wish to download the full SSIS package, here you go: http://www.ssistalk.com/ExportSSISPackages.dtsx

You may also have the following additional error message:
The System Cannot Find The File Specified

Here’s how to fix it, thanks to Silviu Guea, Microsoft.

Create a batch file with the following code. Execute it. Ignore any errors. Try again. If it doesn’t work, you may have to contact Microsoft support or try many uninstall/reinstall combinations. For me, this worked the first time I tried it. Finally, the code:

@rem start batch file
@rem delete the VSTA registry cache from the current user
REG DELETE HKCU\Software\Microsoft\VSTA /f
REG DELETE HKCU\Software\Microsoft\VSTAHost\SSIS_ScriptTask /f
REG DELETE HKCU\Software\Microsoft\VSTAHost\SSIS_ScriptComponent /f

@rem delete the VSTA registration cache for SSIS script task and data flow script component
REG DELETE HKLM\Software\Microsoft\VSTAHost\SSIS_ScriptTask /f
REG DELETE HKLM\Software\Microsoft\VSTAHost\SSIS_ScriptComponent /f

@rem delete the cached files from the HDD
rd /s /q "%AppData%\Microsoft\VSTA"
rd /s /q "%AppData%\Microsoft\VSTAHost\SSIS_ScriptTask"
rd /s /q "%AppData%\Microsoft\VSTAHost\SSIS_ScriptComponent"

rd /s /q "%USERPROFILE%\Local Settings\Application Data\VSTA"
rd /s /q "%USERPROFILE%\Local Settings\Application Data\VSTAHost\SSIS_ScriptTask"
rd /s /q "%USERPROFILE%\Local Settings\Application Data\VSTAHost\SSIS_ScriptComponent"

@rem re-generate the VSTA files for SSIS script task and component
"%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\vsta.exe" /hostid SSIS_ScriptTask /setup
"%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\vsta.exe" /hostid SSIS_ScriptComponent /setup

@rem end batch file

Download file here: vsta_cleanup.txt

You may see this message in your server’s SQL Log file:
“SQL Server has encountered 1 occurrence(s) of cachestore flush for the ‘SQL Plans’ cachestore (part of plan cache) due to some database maintenance or reconfigure operations.”

In the case of MAXDOP changing, if you look before the above event happened, you should see that MAXDOP was changed and hence caused the flush.

This makes sense. If you are changing the MAXDOP setting, all current query plans are worthless as they’re out of date with respect to this parameter. Some plans may now be able to benefit from parallelism, whereas before they could not. Or if constraining MAXDOP, some parallel plans may not be able to work anymore. (Or some combination thereof.) The easiest way to rectify this issue is to simply flush the plan cache and let all plans recompile at their next execution.

A common situation for changing MAXDOP could be for maintenance operations, where during normal operations MAXDOP is constrained to 1, yet while doing weekly work during a maintenance window the DBAs may elect to set MAXDOP to 0 (unrestricted).

So, when you’re scratching your head wondering where your plan cache went, it could be due to administrative tasks.

As always, if you are unsure, it is best to determine the actual version by looking at the files themselves, ie. dtexec.exe, or by confirming the version number in BIDS via Help->About.

While this isn’t a big deal, it is an annoyance. I’ve got the question out to the product team for their response, so stay tuned for more information as it becomes available.

EDIT – Please see Matt Masson’s (SSIS Product Team) comments below.

If you decide to use an ORDER BY in your source and want to tell the SSIS Data Flow that your data is sorted, follow the below steps:

First, ensure that your data is being sorted with the ORDER BY clause. Make note of which column(s) are in the sort and their positions.

Second, open the Advanced Editor for the OLE DB Source component by right-clicking on the OLE DB Source and selecting “Show Advanced Editor…”

Then, click on the “Input and Output Properties” tab.

Then highlight the “OLE DB Source Output Properties” branch and set the “IsSorted” property to True.

Next, expand the “OLE DB Source Output Properties” branch. From here, select the first column under “Output Columns” that corresponds to the first column in your ORDER BY clause. Set its “SortKeyPosition” property to the number 1.

Repeat the last step for each column in your ORDER BY clause, advancing the SortKeyPosition by one each time. (1,2,3,…)

That’s it. Now the SSIS Data Flow will understand and acknowledge that the incoming data is sorted and will not require a Sort Component between the source and a Merge Join component, for instance.

The specific error message is “The SQL Server Execute Package Utility requires Integration Services to be installed by one of these editions of SQL Server 2008: Standard, Enterprise, Developer, or Evaluation. To install Integration Services, run SQL Server Setup and select Integration Services. The package execution failed. The step failed.”

This constraint has been lifted in Service Pack 1 and Cumulative Update 3, each. See: http://support.microsoft.com/kb/961126/


First_Name
John
Adam
Kris
NULL
Paula
NULL
George


’select count(*) from NAME’ will return the value of 7.
’select count(First_Name) from NAME’ will return the value of 5 because there are two NULL values that are being excluded by rule.

So far so good. The bug in this case shows up under conditions where you are COUNTing a column from what I’ll call a “grandchild table.” In other words, if I have a table, SYS.OBJECTS, and it is joined to SYS.COLUMNS, which is then joined to another table (ANOTHERTABLE) that may or may not have matching SYS.COLUMNS in it and you are counting a column (eliminating NULLs) within ANOTHERTABLE, you may get erroneous results.

A working example is below, thanks to Ionel’s repro query included in the Connect bug submission:

select o.object_id,
count(x.column_id) should_be_zero_always

group by o.object_id


You can run the above code in any database, and will likely see that 1s show up in the column titled, “should_be_zero_always.”

As you can see, the above query is going to be quite common where you do not want to filter results from the driving table and are forced to use an outer join.

The data behind the scenes looks like this:

o.object_id c.object_id x.column_id cnt_returns_1_y_n
1131151075 NULL NULL y
1147151132 1147151132 1 n
1147151132 1147151132 2 n
1147151132 1147151132 3 n
1147151132 1147151132 4 n
1147151132 1147151132 5 n
1147151132 1147151132 6 n
1163151189 NULL NULL y
1179151246 NULL NULL y


Where we have a NULL in c, x is also forced to be NULL (even though x is hardcoded to return an empty data set in the example above), COUNT(x.column_id) will return a 1 for this scenario, when it should be returning a zero.

This works correctly in SQL Server 2000, I might add.

The bug is currently being tracked internally at Microsoft, and in theory, no future CTPs (which would be for releases beyond 2008) won’t have the issue, but there is no E.T.A. on when we’ll see a fix in 2005 or 2008. Hopefully by the end of the year if we’re lucky and it doesn’t get de-prioritized.

I would encourage you to review the Connect bug submission and at least vote, but by all means, please leave your feedback on the issue while you are there.

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=380304

(it’s easy [but still undocumented] under SQL Server 2005 – just delete the mru.dat file…)

Connect item: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=424800

First things first. Add a script component to the data flow. When prompted, select “Source” as the component type. (click on images for full sized version)

Next, for clarity’s sake, I’ll rename the default output. (An output simply contains a set of columns and will correlate to the green arrow on the data flow. The more outputs you have, the more green arrows you can use.) I’ll rename the default output, “Output 0″ to “MyOutput.”

Next, I’ll add an output column called, “MyColumn” and its type will be an integer. Be sure to change the type accordingly.

From here, we can edit the script by clicking on the script section on the left of the above window. From there click on the “Design Script…” button. Below is the setup:

Notice how when I type, I am automatically prompted for a list of available items to choose from. One of them is the column I added previously. Let’s pick the column and assign a value of 123 to it. Full script below:

For SSIS 2005:

Imports System
Imports System.Data
Imports System.Math
Imports Microsoft.SqlServer.Dts.Pipeline.Wrapper
Imports Microsoft.SqlServer.Dts.Runtime.Wrapper

Public Class ScriptMain
    Inherits UserComponent

    Public Overrides Sub CreateNewOutputRows()
        MyOutputBuffer.AddRow()
        MyOutputBuffer.MyColumn = 123
    End Sub

End Class

For SSIS 2008, it’s a bit different:
Visual Basic:

Imports System
Imports System.Data
Imports System.Math
Imports Microsoft.SqlServer.Dts.Pipeline.Wrapper
Imports Microsoft.SqlServer.Dts.Runtime.Wrapper

<Microsoft.SqlServer.Dts.Pipeline.SSISScriptComponentEntryPointAttribute> _
<CLSCompliant(False)> _
Public Class ScriptMain
    Inherits UserComponent

    Public Overrides Sub CreateNewOutputRows()
        Output0Buffer.AddRow()
        Output0Buffer.Column = 123
    End Sub

End Class

C#:

using System;
using System.Data;
using Microsoft.SqlServer.Dts.Pipeline.Wrapper;
using Microsoft.SqlServer.Dts.Runtime.Wrapper;

[Microsoft.SqlServer.Dts.Pipeline.SSISScriptComponentEntryPointAttribute]
public class ScriptMain : UserComponent
{

  public override void CreateNewOutputRows()
    {
        Output0Buffer.AddRow();
        Output0Buffer.Column = 123;
    }

}

You can close the script and then click OK on the script component dialog box. Now when you hook this source up to another component, you'll end up with one column with one row with a value of 123.