Patrick

i.e. if you pass in '1/29/2008',0,0 your date range would be 1/27/2008 - 2/2/2008  or 1 week.

/* Example Run

declare @sdate datetime
declare @edate datetime

execute usp_getWeekRange_onDate '12/29/2006',51,0,@sdate output, @edate output

select * from udf_WeekRanges(@sdate, @edate) -- this function can be used to aggregate your data


*/






Create procedure usp_getWeekRange_onDate(
@Datein datetime = null, -- date to base week range on
@weeksPre int = null, -- how many weeks prior to the current week do you want
@weeksPost int = null, -- how many weeks after current week
@DateStart datetime output, --output param for daterange start - inclusive
@DateEnd datetime output -- output param for date range end - inclusive
)
as
begin

--defaults
set @datein = coalesce(@datein, getdate())
set @weeksPre = coalesce(@weeksPre, 0)
set @weeksPost = coalesce(@weeksPost, 0)

--trim times from date passed
select @Datein = convert(char(8),@Datein,112)

--find closest Sunday prior or including @datein
select @Datein =dateadd(dd,-1*(datepart(weekday,@Datein)-1), @Datein)

--calculate date range based on week parameters
set @DateStart = dateadd(dd,(@weekspre)*-7,@Datein)
set @DateEnd = dateadd(dd,6+7*@weekspost,@Datein)


end

create function udf_WeekRanges (@sdate datetime, @edate datetime)
returns @weekTable Table (caldate datetime, rltvWeek int)
as
begin
   
    declare @week int
    set @week = datediff(week,'19950101',@sdate)-1
    while @sdate <=@edate
    begin
        if datepart(weekday,@sdate)=1
        set @week = @week+1
        insert @weektable
        values(@sdate,@week)
        set @sdate = dateadd(dd,1,@sdate)
        end   
    return
    end

You are correct that the week numbers are arbitrary.  However, the requirement is to come up with the easiest way to aggregate on the week number for reporting.  I think having the week number in the date dimension satisfies that requirement but certainly that is just one way of doing it.  Another part of the requirement is to support business users who are creating queries with a reporting tool; they can't use a stored procedure.  Their tool constructs a SELECT statement for them which can use tables, views or functions.

 OK... I agree... Here is the function only version of what I submitted before.

You can use the function to group any table that has date data in it, by week.

 no need to add columns or tables.

Patrick 

------------------------------------------------------------------------------------------------------
--      Example Run for the previous four weeks summary
------------------------------------------------------------------------------------------------------

DECLARE @BeginWeek INTEGER
DECLARE @EndWeek INTEGER
SET @BeginWeek = -4
SET @EndWeek =  -1

DECLARE @today datetime
SET @today = getdate()

SELECT
 WR.GroupWeek
,COUNT(*) AS EmployeesHired
FROM  dbo.fact_EmployeeActivityX f
INNER JOIN udf_WeekRangesTbl(@today,@BeginWeek,@EndWeek) wr
     ON wr.CompDate = convert(char(8),f.fk_HireDate,112)
GROUP BY GroupWeek
ORDER BY GroupWeek


------------------------------------------------------------------------------------------------------
--      This function is all that you need... No need to maintain a table.
------------------------------------------------------------------------------------------------------


Create function udf_WeekRangesTbl(
@Datein datetime, -- date to base week range on
@weeksPre int = null, -- how many weeks before the current week do you want
@weeksPost int = null-- how many weeks after the current week do you want
)

returns @weekTable Table (CompDate datetime, GroupWeek int)

as
begin
   
    declare @week int
    declare @sdate datetime
    declare @edate datetime
   
    set @weeksPre = coalesce(@weeksPre, 0)
    set @weeksPost = coalesce(@weeksPost, 0)

--trim times from date passed
    select @Datein = convert(char(8),@Datein,112)

--find closest Sunday prior to or including @datein
    select @Datein =dateadd(dd,-1*(datepart(weekday,@Datein)-1), @Datein)

--calculate date range based on week parameters
    set @sdate = dateadd(dd,(@weekspre)*7,@Datein)
    set @edate= dateadd(dd,6+7*@weekspost,@Datein)

--fill @weektable
    set @week = datediff(week,'19950101',@sdate)
    while @sdate <=@edate
    begin
        if datepart(weekday,@sdate)=1
        set @week = @week+1
        insert @weektable
        values(@sdate,@week)
        set @sdate = dateadd(dd,1,@sdate)
        end   
    return
    end




------------------------------------------------------------------------------------------------------
--      Sample Data
------------------------------------------------------------------------------------------------------

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[fact_EmployeeActivityX]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[fact_EmployeeActivityX]
GO

CREATE TABLE [dbo].[fact_EmployeeActivityX] (
    [wk_EmployeeActivity] [int] IDENTITY (1, 1) NOT NULL ,
    [fk_HireDate] [datetime] NOT NULL
) ON [PRIMARY]
GO


declare @counter int
set @counter = 2000
while @counter > 0
begin
insert into dbo.fact_EmployeeActivityX(fk_HireDate)
select dateadd(dd,rand()*-770,getdate())
set @counter = @counter-1
end
 

Thanks for the reply.  The function that returns a table is very elegant.  Every data warehouse has a date dimension and there are some benefits to having the CumulativeWeek column in the date dimension.  I would incorporate your function that returns the table in my solution but still keep the CumulativeWeek column in the date dimension.  I agree that based on your solution it's not necessary but there are alot of things done in data warehouses to make things easier for non-technical users and my solution would be an example of that.

Thanks again.

I'm a little confused by looping here by adding a day:

 set @week = datediff(week,'19950101',@sdate)
    while @sdate <=@edate
    begin
        if datepart(weekday,@sdate)=1
        set @week = @week+1
        insert @weektable
        values(@sdate,@week)
        set @sdate = dateadd(dd,1,@sdate)
        end   
    return
    end

It looks like you found Sundays at each end of the range for @sdate and @edate, so why loop day by day looking for a Sunday.  As far as I know, every week since the beginning of time (as far as SQL Server is concerned) had a Sunday.  So why not just loop adding a week instead of a day. It should make your loop 7 times as efficient plus you don't have to check the DatePart.

while @sdate <=@edate
    begin
        if datepart(weekday,@sdate)=1 
        set @week = @week+1
        insert @weektable
        values(@sdate,@week)
        set @sdate = dateadd(dd,1,@sdate)
        set @sdate = dateadd(ww,1,@sdate)
        end   
    return

Then this could be made even more efficient by simply using a numbers table and avoiding the loop altogether:

insert @weektable
select dateadd(ww,TheNumber,@datein), TheNumber
from NumbersTable
where TheNumber between @weeksPre and @weeksPost

 I know, that's a bit of overkill for a small function that is typically just looking for a few weeks of Sundays, but this would scale much better to a bigger solution.

You are correct.  However my idea was that in a data warehousing application it makes sense to put the week number in the date dimension.  This is a table that gets built one time.  My requirement was to run a report for a range of weeks based on a singlwe week ending date;  The range of weeks would be things like current week, last 4 weeks, current week this year versus current week last year, etc.  By having the week in the dimension, you can do a simple where clause that brings back all rows with the week numbers you need.

I just had to implement this functionality in our DW/BI environment and also added a WeekOfYear column to the date dimension, though my code to po***te it was a little different.  In our implementation, 1/6/2008 starts week 1 of 2008.  Your example shows it as week 53.  Why is that?  Our implementation only has 52 weeks per year and, because part of the first week of the year could be in week 52 of the previous year and part of the last week of the year could be in the last week of the current year, I also added a SalesYear column to specify which year the day was actually in for sales reporting on a Sunday-Saturday week. The first 5 days of 2008 are in the SalesYear 2007, WeekOfYear 52, along with 12/30/07 and 12/31/07.  If I didn;t do that and a user selected week 52 of 2008, they would get data for some days in January and some in December.

I don't remember the specifics of the project where I did this but it was something like the week always begins on Saturday and all days in the week belong to that week even if they cross into the next month or even the next year.  As a result you occasionally wind up with a week that includes days that are in the next month (and possibly the next year).