Hi, Jeremy. I believe that's the approach that I've been tossing out for consideration, too.
Having one table of specific calendar events, some of which are manually entered as "one-time" events, others which are inserted dynamically based on info in an "recurring events" table that is consulted when the calendar is viewed. With your approach, how did you handle the change of date or whatever for a specific instance of a recurring event? e.g.: This month's meeting, normally held on the 2nd Tuesday of each month will be on the 3rd Tuesday due to conflict with the Girl Scout meeting... The dynamically created "specific occurrence" would have to be an actual record that could be changed, and code would have to determine if one of the normally dynamically created events should not be created for a month which has the event already on the calendar from the "one-time" events table. In other words, if specific occurrences of recurring events were never changed, actual insertion of recurring events into the specific events table would not be required...just dynamically create the calendar. But when an exception to the recurrence pattern is needed, the system has to account for that somehow... Perhaps a third table to contain specific instances of exceptions to the recurrence patterns, tracked by event and recurrence interval? E.g.: The calendar is asked to display Nov 2004 events. Events from the regular events table are pulled for insertion, then the recurring events table is checked and events for that period matching the recurrence description are created, and finally, exceptions for dynamically created events are checked for in the exceptions table for that period where the event name and whatever else might be needed for identifying the specific dynamic event in question are checked for existence in the initial query. If a specific instance of a normally dynamic event already exists in the events table and would place the events too close together according to the recurring event's description, then that dynamic insertion is bypassed. Make any sens? Thoughts? Thanks for your time and input... Rick -----Original Message----- From: Jeremy Allen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 8:26 AM To: CF-Talk Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events? Hello, We have implemented a solution at elliptIQ a couple of different ways. We store regular calendar events in one table, and when an event has recurrence data we link to another table for storing the recurrence data. We calculate event recurrences and only store the data describing the recurrence pattern. While inserting every event in a recurrence pattern certainly isn't cheating, it isn't robust at all. We simply could not justify the maintenance headaches that presents later on. It can be tempting to justify doing it the "easy" way when just storing a description of the recurrence data and producing events for a range of dates can seem daunting. We have found a way (in T-SQL) to generate recurring events based on a simple description. Eventually we will probably move to some Java component to handle the recurrence patterns, but for now T-SQL works. The idea is simple. You do a self (cross) join that produces a *huge* amount of results. You narrow down that huge amount of results down to your recurrence rules for one date using gigantic a gigantic where clause. There is a lot of surrounding code for that, but the basic idea remains the same. It is not pretty, but it worked. It should be much easier to do recurrence patterns in a more friendly programming language like Java. (FYI: We were able to implement and support the recurrence patterns of calendar events almost exactly as Outlook does). Good Luck! Jeremy Allen Application Architect elliptIQ Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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
