Protocol error in TDS stream

Yesterday I struggled with the following issue in SSIS: I specified a stored proc as the SQL command text in an OLE DB Source in a data flow. When I clicked the Preview button the data I expected was returned. The Columns were also picked up successfully in the source editor.

But everytime I ran the package it failed with the following errors:

SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft OLE DB Provider for SQL Server" Hresult: 0x80004005 Description: "Protocol error in TDS stream"...

SSIS Error Code DTS_E_PRIMEOUTPUTFAILED. The PrimeOutput method on component "OLE DB Source" (1135) returned error code 0xC0202009. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing. There may be error messages posted before this with more information about the failure...

A component has returned from its PrimeOutput call. : 1135 : OLE DB Source
SSIS Error Code DTS_E_THREADFAILED. Thread "SourceThread0" has exited with error code 0xC0047038. There may be error messages posted before this with more information on why the thread has exited...

SSIS Error Code DTS_E_THREADCANCELLED. Thread "WorkThread0" received a shutdown signal and is terminating. The user requested a shutdown, or an error in another thread is causing the pipeline to shutdown. There may be error messages posted before this with more information on why the thread was cancelled...

SSIS Error Code DTS_E_THREADFAILED. Thread "WorkThread0" has exited with error code 0xC0047039. There may be error messages posted before this with more information on why the thread has exited...

After searching the whole day for a solution I finally stumbled accross this post by Adam Machanic. At first sight it did not fit my problem, but out of desperation I decided to give it a bash; and it worked.

I am not going to repeat what he said in his post because he did a brilliant job of it. But in short: tables, views and table-valued UDFs have explicitly defined output columns; and stored procs don't. So SSIS will have guaranteed success in retrieving the correct output columns from tables, views and table-valued UDFs, while a stored proc can return different resultsets based on the input parameters.

As I said before, this does not fit my problem since SSIS did pick up the correct output columns, but I suspect that it missed some crutial metadata which wasn't available in the stored procedure.

Update all index statistics after upgrading a db from SQL Server 2000 to 2005

After upgrading a database from SQL Server 2000 to SQL Server 2005, our application's performance degraded significantly. It was eventually resolved by creating two new indexes in the database.

However, I could not understand how database performance could be impacted negatively by an upgrade. All the indexes which were in the SQL 2000 db exist in the upgraded database.

After googling the topic for a while I came across the following article: Interview with Greg Linwood. Below is an important tip from the article.

Most upgrades I have been involved with have been fairly smooth but some degree of tuning has been required in most cases. One tip worth remembering is to update all index statistics after an upgrade (or simply rebuild all indexes) so that SQL Server’s cost optimizer has the most recent information possible by which to make the best query execution decisions. SQL Server 2005’s cost optimizer is significantly more sophisticated and will generally make the same or better decisions in most cases than it’s predecessor. These improved decisions rarely get noticed (as no-one complains when things improve!) but those which degrade performance sometimes cause the upgrade process to come under un-warranted criticism. Hence, I recommend closely monitoring performance during and after upgrades, just in case the query optimizer makes decisions which “appear” better to it but end up not working out.

Get the SQL Server Instance name from T-SQL

To get the SQL Server instance name with T-SQL use one of the following two statements:

• select @@SERVERNAME
• select SERVERPROPERTY('SERVERNAME')

Important: The SERVERNAME property of the SERVERPROPERTY function uses the computer's current network name. So, if the computer (on which the SQL Server instance is installed) had its network name changed after the SQL Server instance was installed, the SERVERPROPERTY function will pick up the new name - @@SERVERNAME will not! @@SERVERNAME will use the network name of the computer at the time when the instance of SQL Server was installed.

Click here to see more properties of the SERVERPROPERTY function.

Get the names of all tables used in a SQL Server view

I want to be able to quickly identify the tables which make up a SQL Server view. I know I can just open the script and look at it, but I have the following problems:

1. All the scripts are one liners for some strange reason.
2. And some of the views contain large numbers of tables in the joins.

So I came up with this script. It will work in SQL Server 2000 and 2005.

Take note: This script is by no means foolproof, and I haven't tested it very extensively. I am even ignoring the tables' schemas altogether. And if a view and a table would have the same name my script wouldn't know the difference.
But hey, it returns the information I want, so I am happy.

I didn't use the system view INFORMATION_SCHEMA.VIEWS because it truncates a view's T-SQL script in the VIEW_DEFINITION column when the script is too long.

I rather used syscomments because it spreads a view's script over several records when the script is too long for the text column. This enabled me to search the whole script for tables names.
I am not sure if syscomments will split a script in the middle of a word when the script is too long for the text column. If that would be the case I could miss some table names because they can be split.
(syscomments is a system view in the sys schema in SQL Server 2005. In SQL Server 7.0 and 2000 it is a system table in the dbo schema.)