Viewing 15 posts - 19,141 through 19,155 (of 22,226 total)
OUTPUT parameters will do the trick, but they'll only work for single row inserts. If you need to do any batch work, you'll want to look into 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
December 9, 2008 at 7:54 am
Yes, I want direct control over what is run and how it is run within my system. Maintenance jobs are OK, but they can be problematic. I have a lot...
"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 9, 2008 at 7:51 am
check the collation settings between each database, the connection settings (with focus on ANSI settings) and, check the service packs and hot fixes to ensure they're both the same.
"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 9, 2008 at 6:47 am
dastagirid (12/9/2008)
I WANT TO KNOW WHAT IS THE LAST 10 RECORDS IN MY DATABASE TABLES .IS ANY COMMAND IS THERE OR NOT ? ...
You have to ask the last...
"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 9, 2008 at 6:44 am
Is that 11 million on top of the 12 million? You could be looking at more and page splits and index reorgs on top of the stuff that Jack mentioned.
"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 8, 2008 at 9:49 am
Something is shutting down your database. If it's not AUTO_CLOSE, it's something else. Code sure seems like the next best bet.
"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 8, 2008 at 8:10 am
Is it possible the database is being closed by the app when it closes it's connection? That's possible.
"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 8, 2008 at 8:03 am
You've got a scan going against 6 million rows and returning nothing. That's a problem.
I'd suggest checking the indexes on COI_AppDb. Also, the <> construct can cause problems with index...
"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 8, 2008 at 6:40 am
I'm not sure. I do know that the construct where you're using 'SELECT... (SELECT..) + (SELECT...)' is a bit odd and not how I would have done it. As you...
"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 7, 2008 at 7:41 am
sqlguy (12/6/2008)
I knew about using an index to prevent a table scan. What are the most common causes of index scans and how can these be resolved?
I'm not sure...
"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 7, 2008 at 7:30 am
JOINs are pretty much by definition going to be predicated on the PK, an FK or an alternate key that can function as linking mechanism for an FK. 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 7, 2008 at 7:24 am
The second solution is better. The first is going to set up weird relationships. It'll be difficult to query against and hard to maintain. The second solution will make for...
"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 6, 2008 at 4:55 am
Itzik Ben-Gan just released a new book on TSQL Fundamentals. I can recommend that. Once you've got the fundamentals down, you might want to get his book called Inside Tsql...
"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 6, 2008 at 4:52 am
You might want to pick up a copy of Itzik Ben-Gan's Inside SQL Server TSQL Querying. You're missing out on some core logical constructs as to how TSQL works and...
"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 6, 2008 at 4:49 am
It's not anything I've heard of before.
"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 6, 2008 at 4:43 am
Viewing 15 posts - 19,141 through 19,155 (of 22,226 total)