Viewing 15 posts - 18,466 through 18,480 (of 22,219 total)
Lynn Pettis (2/6/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
February 6, 2009 at 7:11 am
Lynn Pettis (2/6/2009)
Grant Fritchey (2/6/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
February 6, 2009 at 6:50 am
Oh, you want to verify that they have BOTH values, but if they have one or the other, it's no good to you?
OK then, how about joining to the table...
"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
February 6, 2009 at 6:48 am
I speak a bit of Southern, some Jersey, some Brooklyn. I'm very fluent in Navy, but really, it's just English with the f-bomb inserted every three to four words.
"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
February 6, 2009 at 6:43 am
How about using an OR statement between the two criteria?
"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
February 6, 2009 at 6:37 am
Sounds like possibly a permissions issue. Are the procs created with different schema's? Do you have permissions to those schema?
"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
February 6, 2009 at 6:34 am
You don't want the second one.
If the procedure is called, does it get the parameters as you outlined or does it get the literal values? Plan guides are extremely picky....
"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
February 6, 2009 at 6:32 am
The answer is the error message. You're trying to insert data that already exists and the primary key constraint, which ensures that the value in a column or columns is...
"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
February 6, 2009 at 6:30 am
Either bulk insert or some method of INSERT... SELECT... You can see examples in the Books Online.
"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
February 6, 2009 at 6:26 am
I wouldn't recommend doing this on a production system, but you could capture statement completion events from a trace. Then you'll see when the call is made from proc b.
However,...
"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
February 6, 2009 at 6:25 am
Yeah, I saw the app. I do understand what you're describing, but I'm 100% with Gail on this. You need to gather statistics to understand exactly where the slow-downs are...
"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
February 6, 2009 at 5:34 am
Where you see proc, substitute query. Sorry I mistyped.
And yes, you do need to determine where the slow down is occuring because it's not from compile time on such simple...
"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
February 5, 2009 at 5:25 pm
DBCC DROPCLEANBUFFERS should only get run as a test. That removes all the data from memory. Based on the queries you've shown, compiles aren't your issue. You're looking at memory...
"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
February 5, 2009 at 5:05 pm
dacto77 (2/5/2009)
The output of my store has 2 tables, how can I insert these 2 tables into another 2 temp tables to manipulate the data? I use this store...
"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
February 5, 2009 at 1:12 pm
SCOPE_IDENTITY will work, but only if you ever insert a single row. If you insert two or more rows, SCOPE_IDENTITY won't adequately cover the situation. That's what the OUTPUT clause...
"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
February 5, 2009 at 12:59 pm
Viewing 15 posts - 18,466 through 18,480 (of 22,219 total)