Viewing 15 posts - 46,846 through 46,860 (of 59,095 total)
Heh... if you need to borrow some porkchops... 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 7:12 pm
Bob Hovious (12/2/2008)
Seeing no way to improve on the CASE logic in the proposed solution
Heh... "Must look eye..." 😛
SET STATISTICS TIME ON
SELECT ID,
...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 6:45 pm
Steps 1 through 3 can can be very easily accomplished... open the file in Excel. Step 4 is a simple "Save As". You don't need to even go near...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 6:25 pm
Same thing, though... use MAX instead of SUM...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 6:17 pm
That'll work... just be advised that it does contain a "partitioned" triangular join and if there're a large number of Pr_ID's for each agent, there will be a big time...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 6:12 pm
Yep... that'll work, too! Haven't tested it for performance, though.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 6:07 pm
1) Would I need to do a union all necessarily? Is it just considered good housekeeping to do it or does it serve a distinct purpose within this statement?
Heh... First,...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 6:06 pm
I know lot's of good folks that like it, but I don't care for Oracle much, either. Many will disagree with me, but I find it too limiting.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 5:57 pm
jeffkretz (12/2/2008)
Gaby Abed (12/2/2008)[hr
Agreed...I'm working on my MCTS for SQL 2005 but I plan to emphasize my experience first on the resumes and keep the certification at the end, probably...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2008 at 2:04 pm
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
Viewing 15 posts - 46,846 through 46,860 (of 59,095 total)