Viewing 15 posts - 21,961 through 21,975 (of 59,098 total)
Then Eirikur's code will do it for you. Do you understand how it works?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2015 at 12:02 pm
Glad it worked out, Mick. Just to be sure, do you understand how/why it works?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2015 at 10:07 am
It may be that having the clustered index on the hash would work faster on the lookups, especially if it were a unique index that was guaranteed to be unique...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2015 at 9:41 am
anu.anu4u (1/11/2015)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2015 at 9:18 am
If you insert the results into a table variable rather than individual variables, your final act could be to select the MAX date from that table variable.
Step 2 would be...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2015 at 9:03 am
prabhu.st (1/11/2015)
as of now the query is taking 19 seconds to bring the result set with pagination for 300454 records.
Are you saying that (and it looks like it from...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2015 at 8:36 am
The clustered index is always added to the non-clustered index.
I have to say, you've done a remarkable job. You tried the "obvious" method and that took 50 minutes. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2015 at 9:49 pm
The question now is, do you understand? After checking out Google on some of the things I suggested and if you're still having problems, c'mon back and post what...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2015 at 9:23 pm
Assuming that a parameter called @pSomeDate is a VARCHAR parameter to take the '03/2011', the following should do it.
WITH
cteStartOfMonth AS
(
SELECT StartOfMonth = DATEADD(mm,CAST(LEFT(@pSomeDate,2) AS INT)-1,RIGHT(@pSomeDate,4))
)
SELECT yada, yada, yada
...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2015 at 9:18 pm
Siva Ramasamy (1/10/2015)
Thanks for looking into my question.
I am trying to shrink a 170 GB tempdb file to 160 GB. There is more than 30 GB available in...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2015 at 8:58 pm
Grant Fritchey (1/10/2015)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2015 at 8:43 pm
I'm not sure it's just a screen reader having that problem. I don't use a screen reader and I see that a lot. Even Steve Jones has one...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2015 at 2:02 pm
Personally, I sometimes think some of that is a line of hooie from SAN admins that have their own agenda or are, maybe, just lazy. I'm not a SAN...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2015 at 2:00 pm
Still, there are some physics involved and people tend to forget that when it comes to SANs. The more sets of read/write heads and platters (collectively referred to as...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2015 at 1:48 pm
From the article
Ultimately we all want the same thing. Better software delivered to customers faster. We want to Ship Safe, and Ship Often.
Ah, if only THAT were true and then...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 10, 2015 at 1:41 pm
Viewing 15 posts - 21,961 through 21,975 (of 59,098 total)