Viewing 15 posts - 50,941 through 50,955 (of 59,098 total)
p.s. For future reference, it's almost always going to be a huge performance drain to try to join to aggregated columns like you have. Preaggregation using a temp...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 7:44 am
I believe every one has hit all the hot spots... Carl's last post should be a big help, as well. The problem is that the derived table in the...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 7:41 am
That covers just about all of it... can't think of anything else to check unless the WHERE clauses have a formula in one and not the other.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 7:23 am
Grant is correct. Tell us what needs to be done... not how to do it. There's usually no need for any form of RBAR. Post some data...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 7:21 am
karthikeyan (4/29/2008)
I have refined the above code as
DECLARE @DateStart DATETIME
DECLARE @DateEnd DATETIME
SELECT @DateStart = '04/Apr/2007', @DateEnd = '29/Apr/2008'
SELECT convert(Datetime,'01'+'/'+convert(varchar,DatePart(MM,DATEADD(mm,N-1,@DateStart)))+'/'+convert(varchar,DatePart(YY,DATEADD(mm,N-1,@DateStart))),103),
DateAdd(DD,-1,convert(Datetime,'01'+'/'+convert(varchar,DatePart(MM,DATEADD(mm,N,@DateStart)))+'/'+convert(varchar,DatePart(YY,DATEADD(mm,N,@DateStart))),103))
FROM dbo.Tally
where DateAdd(DD,-1,convert(Datetime,'01'+'/'+convert(varchar,DatePart(MM,DATEADD(mm,N,@DateStart)))+'/'+convert(varchar,DatePart(YY,DATEADD(mm,N,@DateStart))),103)) <= @DateEnd
I got the below output:
Apr...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 7:16 am
I guess I didn't know you were a "bubble head", Grant. I was the lead ping jockey on SSN 604... did a little time on the Parche (637 stretch...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 7:12 am
Adrian's code does create and execute "one big update" statement as you've asked... have you tried it on a test table?
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 7:07 am
For a single result set that you can join to...
--===== Declare your parameters
DECLARE @pYear INT, @pMonth INT
--===== Set the parameters (simulates a proc or udf parameters)
SELECT @pYear = 2008,
...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 2:24 am
To get all of the dates in the range all at once, then the following will do it for you...
--===== Here are the two parameters you wanted
DECLARE @DateStart DATETIME
DECLARE @DateEnd...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 2:15 am
Well... lemme shift gears here, a bit. You say you want a "text representation" of the matrix of 100,000 columns and 10,000 rows... that's 1,000,000,000 or a Billion "cells"...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 1:35 am
Understood... I was agreeing with you...:)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 28, 2008 at 5:13 pm
Lemme ask again... what's in the TEXT column?
--Jeff Moden
Change is inevitable... Change for the better is not.
April 28, 2008 at 5:09 pm
virgo (4/28/2008)
:w00t: ok Jeff....just in some cases i need to do that way....am using sql server 2005....thanks much for ur reply
Ian's method using ROW_NUMBER() OVER will work just fine, then.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 28, 2008 at 5:06 pm
Zactly...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 28, 2008 at 7:15 am
Heh... thanks Grant... I'm just a wee bit embarrased that I didn't pick up on that before I posted the question. 😛 More COFFEE!:hehe:
--Jeff Moden
Change is inevitable... Change for the better is not.
April 28, 2008 at 7:02 am
Viewing 15 posts - 50,941 through 50,955 (of 59,098 total)