Today we had trouble with the CATCH block in a T-SQL script which did not execute after an error in the TRY block. It turned out that there are times when your TRY block can fail and the CATCH block will get bypassed altogher.
Click here or on the title of this article to see the article by Alexander Kuznetsov about exactly this problem.
Our problem was a compile error: a column name we referenced in a join statement no longer existed.
Showing posts with label SQL Server 2005. Show all posts
Showing posts with label SQL Server 2005. Show all posts
Tuesday, February 16, 2010
Wednesday, December 3, 2008
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:
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.
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.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.
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...
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.
Tuesday, July 15, 2008
Get all the dates in a range
Use this T-SQL script to get all the dates in a specified date range.
Please note that it will only work in SQL Server 2005 or later.
Please note that it will only work in SQL Server 2005 or later.
Monday, June 9, 2008
SQL Server 2005 Performance Dashboard Reports
Last week our dba resolved serious SQL Server performance issues very effectively using SQL Server Performance Dashboard Reports.
Our server's four dual core processors were averaging 99.73% for a couple of days. After monitoring the situation with SQL Server 2005 Performance Dashboard Reports and implementing the suggested performance enhancements, our server's CPUs are now working at between 12% and 60%.
More about Microsoft SQL Server 2005 Performance Dashboard Reports:
Download it here.
Our server's four dual core processors were averaging 99.73% for a couple of days. After monitoring the situation with SQL Server 2005 Performance Dashboard Reports and implementing the suggested performance enhancements, our server's CPUs are now working at between 12% and 60%.
More about Microsoft SQL Server 2005 Performance Dashboard Reports:
"The Microsoft SQL Server 2005 Performance Dashboard Reports are used to monitor and resolve performance problems on your SQL Server 2005 database server."
"The information captured in the reports is retrieved from SQL Server's dynamic management views. There is no additional tracing or data capture required, which means the information is always available and this is a very inexpensive means of monitoring your server."
Download it here.
Thursday, June 5, 2008
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.
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.
Thursday, May 22, 2008
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:
Click here to see more properties of the SERVERPROPERTY function.
- select @@SERVERNAME
- select SERVERPROPERTY('SERVERNAME')
Click here to see more properties of the SERVERPROPERTY function.
Thursday, May 15, 2008
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:
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.)
- All the scripts are one liners for some strange reason.
- And some of the views contain large numbers of tables in the joins.
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.)
Wednesday, May 14, 2008
Undocumented Stored Procedures
Apparently there are extended stored procedures which are not documented in the Books Online. In this post I want to create a list of those stored procs with links to articles about how to use them. So far I have only one proc, but I will update this post as soon as I come across more.
I don't think this one is an extended proc, but also undocumented:
- xp_ReadErrorLog (SQL Server 2005)
I don't think this one is an extended proc, but also undocumented:
EXEC sp_MSForEachTable 'EXEC sp_spaceused [?]' - It allows one to execute a T-SQL statement against each table in a database.
Wednesday, April 23, 2008
SQL Server 2005 ROW_NUMBER() function
Here's an example of how to use the row_number() function which became available in SQL Server 2005.
Click here for a detailed description of the syntax.
Click here for a Google search on this topic.
Run this script against the AdventureWorks sample database in SQL Server 2005. See how the row_number() function numbers the line items per sales order:
select
SalesOrderNumber,
LineItemNo = row_number() over(partition by SalesOrderNumber order by SalesOrderDetailID),
Product = p.Name,
OrderQty,
UnitPrice,
UnitPriceDiscount,
LineTotal
from
Sales.SalesOrderHeader h
inner join
Sales.SalesOrderDetail d
on
d.SalesOrderID = h.SalesOrderID
inner join
Production.Product p
on
p.ProductID = d.ProductID
Click here for a detailed description of the syntax.
Click here for a Google search on this topic.
Run this script against the AdventureWorks sample database in SQL Server 2005. See how the row_number() function numbers the line items per sales order:
select
SalesOrderNumber,
LineItemNo = row_number() over(partition by SalesOrderNumber order by SalesOrderDetailID),
Product = p.Name,
OrderQty,
UnitPrice,
UnitPriceDiscount,
LineTotal
from
Sales.SalesOrderHeader h
inner join
Sales.SalesOrderDetail d
on
d.SalesOrderID = h.SalesOrderID
inner join
Production.Product p
on
p.ProductID = d.ProductID
Subscribe to:
Comments (Atom)