January 10, 2010 at 9:04 pm
Comments posted to this topic are about the item 4-4-5 Calendar Functions, Part 2
January 11, 2010 at 6:41 am
Thanks for nice article.
Also function which returns the Weeks is more usefull for retail programs and like-for-like discussions.
As you now sql server's DATEPART weeknumber function does not return the real Week number according to the
4-5-4 calendar...
For example if your week starts with Monday.
01/01/2010 Friday
02/01/2010 Saturday
03/01/2010 Sunday
04/01/2010 Monday
Sql Server returns 1 for weeknumber of 01/01/2010 but it is the 53th week of 2009.
Sql Server returns 2 for weeknumber of 04/01/2010 but it is the 1st week of 2010.
So the new function should return 2009W53 2010W01
anyway thanks again 😉
January 11, 2010 at 7:16 am
Every time I read these articles about 4-4-5 my head hurts... and I vow again and again to make sure to not take a job with a company that follows this practice 🙂
January 11, 2010 at 11:46 am
Thanks for taking the time to put together this article.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
January 13, 2010 at 7:11 am
Thanks for the comments. It somehow slipped past me that the article was published already. Any other comments are much appreciated.
Cliff
February 7, 2010 at 9:01 pm
Thanks for the article. I'm actually working on fiscal based periods at the moment, and have opted to have all of the periods defined in a setup-type table.
E.g.
Period # | Fiscal Year # | Quarter # | Start Date | End Date
That way, the end-user is responsible to define the fiscal year, and no calculations are required.
Your thoughts?
February 8, 2010 at 7:35 am
Using a table is preferable. You'll see better performance out of queries. Something interesting that came up during the comments on Part 1 of the article is performance issues with Date comparisons, especially the BETWEEN operator, and possible ways to increase performance. You might want to check that out.
July 15, 2010 at 10:20 am
A table is preferrable for performance reasons. I used a table function because i can pass in what factory location since each of our sites has a different calendar of workdays and holidays; and of course i had to revised it during development several times because the "requirements" kept changing.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply