Viewing 15 posts - 19,066 through 19,080 (of 22,219 total)
Is the field a number field, int, bigint, numeric, decimal. If not, it won't allow you to create an identity.
"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
December 15, 2008 at 11:59 am
I'd strongly suggest you use Matt's solution. The one you have is going to perform pretty badly.
"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
December 15, 2008 at 10:18 am
Then you're just a little bit stuck. You can't refer to objects that don't exist in the query, even if it's just in an IF statement. Why couldn't you use...
"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
December 15, 2008 at 9:12 am
Depending on the data types in question, there's nothing inherently wrong with a compound natural key. I'm not sure why it would matter to the end user though.
"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
December 15, 2008 at 9:08 am
If I understand the problem, then I'd suggest instead of having three queries for the three version, have three procedures and then, depending on the version, using your IF statement,...
"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
December 15, 2008 at 8:55 am
I'm pretty similar in approach, Profiler is my bestest buddy.
After that, since you're in 2005, you can look at sys.dm_exec_query_stats for an immediate picture into which queries are running...
"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
December 15, 2008 at 8:49 am
Absolutely. No issues at all.
"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
December 15, 2008 at 7:48 am
It sounds like you can do this with a trigger or with a stored procedure. While I'm not a fan of triggers, if you need one, you need one. 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
December 15, 2008 at 6:50 am
Krishna_DBA (12/13/2008)
Why dont use DTA tool and apply the recommendations from there? I am just wondering.....
Primarily because it's unreliable. Your time is better spent learning how to do indexing yourself...
"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
December 15, 2008 at 6:29 am
Are the inserts & deletes done all the time or in discrete batches? If the latter, you can leave indexes off until you need them and then add them. If...
"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
December 15, 2008 at 6:25 am
And you use this to reduce the number of calls back and forth between the stored procedure and the application calling 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
December 15, 2008 at 6:20 am
Also, by default, every proc exits with either a 0 for success or a 1 for failure as a return code on the proc. You can check for this in...
"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
December 15, 2008 at 6:10 am
So, if you run the TSQl to create your function, you can't see it? Are you looking through the GUI? If so, make sure you're hitting refresh. If you can...
"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
December 15, 2008 at 6:07 am
And here, the thread died, a horrible, messy death.
"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
December 15, 2008 at 6:05 am
IT isn't going away any time soon. If it does, we'll be far to busy eating each other to worry about where a pay check is going to come from.
"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
December 15, 2008 at 5:51 am
Viewing 15 posts - 19,066 through 19,080 (of 22,219 total)