Viewing 15 posts - 6,466 through 6,480 (of 22,219 total)
Another vote for the OUTPUT clause. That link is to the documentation.
"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
April 4, 2015 at 3:15 am
baiju krishnan (4/4/2015)
Hi following is a working code
declare @dte as datetime='2015-04-01'
declare @StDt as Datetime = DATEADD(mm,DATEDIFF(mm,0,@dte), 0)
declare @EnDt as datetime = DATEADD( DD, -1, DATEADD(mm,DATEDIFF(mm,0,@dte) + 1, 0));
DECLARE @query...
"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
April 4, 2015 at 3:13 am
If the partitioning is working for your in production and you're actually using it, removing it doesn't make a lot of sense. If this other server is not a production...
"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
April 4, 2015 at 3:09 am
NVARCHAR (MAX) is not supported. I mistyped that. Still, everything but my typo is what I meant to say.
"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
April 3, 2015 at 4:05 pm
It could be a huge number of things. No way to tell you based on the information we have.
I'd suggest monitoring the system in order to understand what's happening with...
"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
April 3, 2015 at 3:59 pm
Really short answer, VARCHAR(MAX) is not supported. You can't put that table into columnstore.
Long answer. Columnstore indexes are extremely useful for aggregation queries. They also work ok for some types...
"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
April 3, 2015 at 3:55 pm
Eirikur Eiriksson (4/3/2015)
Grant Fritchey (4/3/2015)
"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
April 3, 2015 at 3:23 pm
You should be able to simply run CAST against the data to put it into the right data type in the view. But, if the data is not formatted properly,...
"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
April 3, 2015 at 11:17 am
Sounds like a great place to put a wrapper proc. Have it have the same name and parameters as your current procedure. Then, inside it, it figures out which of...
"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
April 3, 2015 at 11:14 am
Sean Lange (4/3/2015)
Grant Fritchey (4/3/2015)
Koen Verbeeck (4/3/2015)
It's Friday and I'm grumpy...http://www.sqlservercentral.com/Forums/Topic1674050-3412-1.aspx
OK. Funny, very funny, but a little uncool.
I found it a rather fitting response to somebody who clearly seemed they...
"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
April 3, 2015 at 7:33 am
Koen Verbeeck (4/3/2015)
It's Friday and I'm grumpy...http://www.sqlservercentral.com/Forums/Topic1674050-3412-1.aspx
OK. Funny, very funny, but a little uncool.
"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
April 3, 2015 at 6:37 am
Instead of killing all the processes directly, you could run your query, capture the ones you're going to kill, then simply set the database to restricted user and use rollback...
"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
April 3, 2015 at 6:30 am
You're doing an INSERT and then want to use the values inserted later within the same query? How about using the OUTPUT clause to capture the values into either variables...
"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
April 3, 2015 at 6:24 am
Try rewriting it to:
SELECT @KUR = RATES1 FROM dbo.L_DAILYEXCHANGES WHERE EDATE= @T1 AND CRTYPE =1;
But, it's only going to work if that only returns a single value. If it returns...
"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
April 3, 2015 at 6:21 am
Rather than just killing the processes, understand what those processes are doing and why you're getting "massive" locks from them. And locking is a normal part of inserts, so it's...
"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
April 3, 2015 at 6:18 am
Viewing 15 posts - 6,466 through 6,480 (of 22,219 total)