Viewing 15 posts - 7,651 through 7,665 (of 22,232 total)
Each of those procedures will commit, individually. Even though one of them doesn't have the COMMIT statement. SQL Server runs in autocommit transaction mode by default.
"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
July 31, 2014 at 4:32 am
cdm33.com (7/30/2014)
This code has hundreds of lines to it. I've got no clue what it does. I'm not going to put something like this on a production server...
"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
July 31, 2014 at 4:28 am
Oh, and if you are in Europe, I'm doing a full day on execution plans at SQL Server Days.
"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
July 31, 2014 at 4:24 am
I'm putting on a full day of query tuning at Connections in September and at the PASS Summit in November. The advantage of going to either of these is that...
"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
July 31, 2014 at 4:23 am
Sounds like you're trying to make it smaller than you have data in it. You can't do that.
"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
July 31, 2014 at 4:11 am
cunningham (7/30/2014)
I made a slight mistake, the query is no sp_executesql, it is sys.sp_execute. Is this the same thing?
That's for executing prepared statements. Different than sp_executesql because the prepared statements...
"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
July 31, 2014 at 3:57 am
patrickmcginnis59 10839 (7/30/2014)
Then whats the problem with defending SO?
I wasn't aware there was one. Someone offered an opinion. You disagreed. Others disagreed with you. Etc.
Where was anyone shutting 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
July 30, 2014 at 12:33 pm
Or, assuming you can get it in a delimited fashion, using Jeff's Tally Table methods [/url]to turn that into a derived table that you can then JOIN on.
"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
July 30, 2014 at 11:40 am
The choice for an ad hoc query, a parameterized query, stored procedure, or sp_executesql are not made internally by SQL Server. They're all made by the application. There's nothing 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
July 30, 2014 at 10:46 am
patrickmcginnis59 10839 (7/30/2014)
Grant Fritchey (7/30/2014)
patrickmcginnis59 10839 (7/30/2014)
"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
July 30, 2014 at 10:34 am
patrickmcginnis59 10839 (7/30/2014)
"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
July 30, 2014 at 9:05 am
Sean Lange (7/30/2014)
Grant Fritchey (7/30/2014)
I would never suggest we denormalize our structures in most normal situations for many...
"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
July 30, 2014 at 8:41 am
Koen Verbeeck (7/30/2014)
Grant Fritchey (7/30/2014)
Koen Verbeeck (7/29/2014)
Grant Fritchey (7/29/2014)
"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
July 30, 2014 at 8:38 am
SQLRNNR (7/30/2014)
Grant Fritchey (7/30/2014)
I'm going to throw one more datatype thing out there.
The use of GUIDs as your Clustered Index will COST you plenty of space. Changing the clustered 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
July 30, 2014 at 8:31 am
Sean Lange (7/29/2014)
Actually normalization (more tables) causes slower performance.
I want to let this go, but I just can't.
No. Not true.
Everything, everything, within a structured storage engine comes with trade-offs...
"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
July 30, 2014 at 8:23 am
Viewing 15 posts - 7,651 through 7,665 (of 22,232 total)