Viewing 15 posts - 16,426 through 16,440 (of 22,219 total)
Use the TRY/CATCH construct. It provides the most power for what you need. There's an introductory article here[/url].
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 28, 2009 at 6:51 am
Just for curiousity, what did you do to solve the performance issue?
I see a function on a column in the WHERE clause that will prevent index use. Was that it?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 28, 2009 at 6:48 am
None that I'm immediately aware of. I'd have to do a search for it.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 27, 2009 at 5:18 am
jcrawf02 (9/25/2009)
Grant Fritchey
You going to the summit?
I got this picture in my head of Grant in mountaineering gear on the slopes of Everest as he passes Alvin...
And there's...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 1:24 pm
Roy Ernest (9/25/2009)
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 1:22 pm
Alvin Ramard (9/25/2009)
Grant Fritchey (9/25/2009)
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 1:21 pm
Yeah, it'll convert an int parameter to a bigint... but, what happens the first time you pass a bigint to the int parameter? You're going to have to update those...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 1:01 pm
I just checked with our systems guys, they say it's possible, but they've never done it and don't recommend it.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 12:37 pm
Also, is the data exactly the same on both servers. Are you passing identical parameters on both servers. Assuming both of the above are yes, are the indexes and structures...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 12:32 pm
It stays on until you turn it off or turn it on for another table, so did you test the inserts to tableA at some point in the past?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 12:28 pm
Usually, delete the data in the referring tables first. Alternatively you could set up your foreign key constraints with cascading deletes. This is considered a dangerous approach, so it's not...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 12:26 pm
Alter the table, add the column as nullable, copy the data over, drop the other column at a later date. That should minimize downtime on the system.
Otherwise, you've outlined the...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 12:24 pm
Scalability Experts has a free tool called the SQL Server 2008 Upgrade Assistant. I used it a few times and it does most of what you're looking for. I'd check...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 12:18 pm
Alvin Ramard (9/25/2009)
Roy Ernest (9/25/2009)
Still a long way to go. I am getting lots of positive feed backs from the people who attend. They are coming up...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 11:42 am
Alvin Ramard (9/25/2009)
Roy Ernest (9/25/2009)
Still a long way to go. I am getting lots of positive feed backs from the people who attend. They are coming up...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 11:38 am
Viewing 15 posts - 16,426 through 16,440 (of 22,219 total)