Viewing 15 posts - 46,861 through 46,875 (of 59,101 total)
Heh... sorry... just over a year late on this one...
Leap year calculations don't need to be complex in SQL Server...
ISDATE(STR(@Year,4)+'0229')
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 11:30 am
Thought I'd revisit this one... calculation for Leap Years can be a lot more simple...
ISDATE(STR(@Year,4)+'0229')
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 11:23 am
... or a nice article on SSC, Phil. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 5:24 am
vijinarav (12/1/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 11:38 pm
Ninja's_RGR'us (12/1/2008)
Steve Jones - Editor (12/1/2008)
Heh... thanks for the vote of confidence, but I learn something new about T-SQL everyday even if it's how to NOT do something. 😀
I'd bet...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 11:27 pm
You can simulate an indexed view... just make a preaggregated table as suggested before.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 10:15 pm
puneet shadija (12/1/2008)
since we have many threads, which may concurrently try to insert a record to this table, thus I have used this lock to prevent this from happening
You just...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 8:54 pm
As previously posted, WAITFOR DELAY will get you to the nearest 3 milliseconds. If you want microseconds, just to a couple of PRINT statements.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 8:40 pm
That's exactly what SQL Server 2008 is... the ultimate service pack for 2005 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 8:38 pm
I store the output in two tables and do a Full Outer Join on their key columns to compare.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 8:35 pm
Much better... if you have a joined update, the object of the join MUST be in the FROM clause or you could end up pinning 4 cpu's to the wall...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 8:28 pm
Lynn Pettis (11/28/2008)
Just playing the Devil's Advocate here, but couldn't you consider user training of an application using SQL Server 2005 as the database backend a "demonstration use"?
Ya beat me...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 8:18 pm
Simon,
You're kinda new to the forum... take a look at the link in my signature below to get better, tested answers quicker...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 8:16 pm
For more infomation on the method used above, please see the following link...
[font="Arial Black"]Solving the "Running Total" & "Ordinal Rank" Problems in SS 2k/2k5
[/font][/url]
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 8:07 pm
This is how you do ROW_NUMBER() OVER in SQL Server 2000 with any performance at all. It's almost as fast as ROW_NUMBER () OVER...
Using the test data previously provided...
--=====...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2008 at 8:05 pm
Viewing 15 posts - 46,861 through 46,875 (of 59,101 total)