Hi, Webguy... I think I'm following your logic.
Looks like I'm thinking of something similar, but having a table for "one-time" events, plus a second table to hold "descriptions" of recurring events that would be dynamically inserted into the "one-time" events table, if the calendar display required the individual occurences to appear. At that time, an instance of a "recurring event" would become a "one-time" event in the first table. By doing it this way, I have a table of recurring event "descriptions" to draw upon dynamically, but also have specific occurences of these events to allow changes to those specific occurences of recurring events. Does that make any sense? By putting out the information from a structure, rather than from specific records of events, the "2nd Tuesday of the month" meeting couldn't be changed to the "3rd Tuesday of the month" for April only. Does that seem correct? Your method would avoid having a table full of thousands of records trying to cover all "one-time" and "recurring" event instances, but it would also not allow for changes to specific instances of "recurring" events? Correct? Assuming an average of 50 events per week, of specific instances of "one-time" and "recurring" events, that would amount to about 2600 specific calendar events per year and if I allowed the calendar to be consulted at most, say, 2 years in advance, I'd have a table with about 5200 records? Too many? Also, I could limit the actual creation of specific event records of all intervals to up to two years, thereby limiting actual specific event records to about 5200 at one time in the table, but for anyone consulting the calendar for, say, 5 years in advance to check on what day an event falls for long-range planning, I could use an array to hold any info beyond 2 years and output anything beyond 2 years from today's date from that array, and everything else from the actual event records table... Limits records, allows long-range calendar consultation, and allows specific occurence manipulation of recurring events for up to two years in advance. And I guess if someone wanted to change a specific instance of a recurring events 5 years in advance, I could always create a specific instance record for that change in the actual event table. I'd have to setup the code to check for an existence of a specific occurence of a recurring event, before outputting specific instances that are created dynamically from the "description" table, in order to prevent having the regularly scheduled "2nd Tuesday of the Month" meeting show up that is created dynamically from the "description" table, while at the same time having that occurence, which was changed and made an actual record in the events table, showing up on the "3rd Tuesday of the Month" for April. That might be a way to make sure changed specific occurences supercede and eliminate dynamic insertions. Aaaahhhhh! Too much thinking for 3 minutes before midnight! :o) What do you think? Thanks for your time and input. Rick -----Original Message----- From: webguy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 10:13 AM To: CF-Talk Subject: webguys solution number 1 - RE: How to handle Calendar Scheduling of Recurring Events? This is roughly how I've done it in the past, from memory so excuse typos When you record the events you create a seeddate ( eg the day the event starts ) interval ( weekly etc) <cfset norecurrance = 0> <cfset daily = 1> <cfset weekly = 2> <cfset monthly = 4> <cfset yearly = 8> enddate (never or a date) sample date seeddate enddate recurs ------------------------------------------- 24/1/2002 never(null) yearly 24/1/2002 never(null) weekly 24/1/2002 24/3/2002 monthly 24/1/2002 never(null) daily Now when you go to select your records week view (starting on date A ending on date B) get events where enddate > A and - all daily events - all weekly event - monthly events where day(seeddate) between day(a) and Day(b) - yearly events where month(seeddate) between month(a) and month(b) and day(seeddate) between day(a) and day(b) Something like that Now you have your recordset you need to build your recurring events . I've done this a few different ways in the past, one way for example is to loop over the records and expand out recurring events, creating a array for each day (named in the format DD_MM_YYYY). This allows you to do some cool gui stuff like having a band across days for events which continue daily from date x -> date z ..It also means you only need to loop over the recordset once, as opposed to once to each day you want to display [for each day, loop over the records for event related to that day ] which would equal (31 * amount of records) in a month view for example. eg <cfloop query> if interval not 0 switch interval daily everyday events (easy) start at date weekly, monthly, yearly don't need to expand these - they just happen once in week view. </cfloop> (actually week is easy month is the most difficult) so now you should have arrays named in the format DD_MM_YYYY for each day. now display your week <cfloop from=0 to=6 index=i> <cfset currentday = dateform(dateadd("d",a,i),"DD_MM_YYYY")> <cfif isdefined(currentday)> loop over array output the events (details stored in structures) <cfelse> no events </cfif> </cfloop> Thats one way. Excuse the mess its off the top of my head. :-) WG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
