Viewing 15 posts - 19,381 through 19,395 (of 22,219 total)
By the way, what's DBAccess?
"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
October 24, 2008 at 11:39 am
OK, you lost me. I can't tell what you're trying to do there.
You can't subtract one result set from another one and you have to have FROM clauses to...
"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
October 24, 2008 at 11:38 am
Small tables, especially those that occupy less than one extent (that's 8 pages) generally won't defragment.
"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
October 24, 2008 at 11:32 am
If I understand the question correctly, you're looking for the UNION operator. To combine the three statements:
SELECT...
FROM....
WHERE...
UNION
SELECT...
FROM..
WHERE...
UNION
SELECT...
FROM...
WHERE...
[/code]
"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
October 24, 2008 at 9:08 am
And is that a language term or a mathematic/engineering term?
"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
October 24, 2008 at 7:58 am
Actually, you can change the PK from nonclustered to clustered without dropping it. Here's an example:
CREATE TABLE t1
(c1 INT NOT NULL);
ALTER TABLE t1 ADD CONSTRAINT pk_t1 PRIMARY KEY NONCLUSTERED (c1);
CREATE...
"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
October 24, 2008 at 7:41 am
Funny, I was wondering the same thing. I even did a google search to try to track it down.
"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
October 24, 2008 at 7:00 am
Backups, absolutely.
And, this one does make people crazy, but I've been insisting on it for over a decade now... a tested script to deploy changes to production. No winging 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
October 24, 2008 at 6:06 am
The issue I'm seeing is that Nested Loop operator, NodeId = 17, right before the Hash Match, NodeId = 16, that's performing the aggregation. Two issues there, first, it's using...
"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
October 23, 2008 at 10:53 am
Buck Woody addressed this question in a recent blog post:
http://blogs.msdn.com/buckwoody/archive/2008/10/20/erd-designer.aspx
"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
October 23, 2008 at 7:11 am
I got that link from our local Microsoft rep. I'm assuming it's on the RSN schedule (Real Soon Now).
"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
October 23, 2008 at 7:09 am
If you don't have a clustered index on the table, I'd at least put one on that ID column. After that, take a look at the execution plans to determine...
"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
October 23, 2008 at 6:38 am
There are exceptions, but by and large, every table should have a clustered index. The nonclustered indexes have to use RID to track down the data, which is generally 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
October 23, 2008 at 6:33 am
I'm not aware of a resource for making these types of decisions except for common sense and experience. You could go to a consulting firm or bounce the ideas off...
"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
October 23, 2008 at 6:25 am
What about the Dudettes?
Anyway, short of installing it & checking the version, I'm not sure what you could do.
"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
October 23, 2008 at 6:14 am
Viewing 15 posts - 19,381 through 19,395 (of 22,219 total)