Joshua:
I see how your implementatino would work by using the following tables:
(I think... ;o)
Table 1 (tblEvents) - contains all event data
eventID: Identity/PK field for unique id
... All other relevant event data except date ...
Table 2 (tblEventDates) - contains 3 columns:
edID: Identity/PK field for unique id
eventID: foreign key that ties to the tblEvents entry
eventDate: Date of the event
If a person was inserting an "event" that was marked as recurring,
then the code would process all the specific instances of the event
and put the dates for the events in table 2 above as individual records
for each occurence for a certain time period, say, for two years, then
the other event information (all but the date) goes into a table once...
Then when the calendar is pulled up, the event details and the dates
of all occurences are pulled to gether and displayed.
Potential problems that I see:
The approach would seem to limit seeing future occurrences of an event
beyond the limit set for the initial insertion. i.e., if the timespan limit
for creation of specific events was the end of 2004, then recurring events
for 2005 would not appear. Therefore, for anything beyond that limit,
another insertion of the "recurring event" would have to be made at a later
time,
which would run counter to the nature of a "recurring event."
Also, since the table "tblEvents" would only contain a description of
"multiple"
occurrences of an event, the details could not be changed for one
occurrence,
say, a location change, without changing all occurrences of the event.
Would this be correct?
Rick
-----Original Message-----
From: Rick Faircloth [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 15, 2003 1:30 PM
To: CF-Talk
Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events?
Trying to figure out just how your approach would be implemented...
You're suggesting one table for everything?
And I can't get my brain around an implementation that would handle your
approach:
>For example, suppose you created an implementation to support patterns
>like, "the first day of every month from 1/1/97 to 1/1/98." The former
>is a recurring pattern, but could easily be turned into a one time event
>by thinking of it as, "the first day of every month from 1/1/91 to
>1/1/98."
Wouldn't that pattern have to be turned into specific occurrences at some
point?
Rick
-----Original Message-----
From: Matt Liotta [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 15, 2003 12:06 PM
To: CF-Talk
Subject: RE: RE: How to handle Calendar Scheduling of Recurring Events?
For example, suppose you created an implementation to support patterns
like, "the first day of every month from 1/1/97 to 1/1/98." The former
is a recurring pattern, but could easily be turned into a one time event
by thinking of it as, "the first day of every month from 1/1/91 to
1/1/98." While it may seem silly to describe even one time events using
a similar pattern to recurring events, it does give a system a single
way to deal with events, which IMHO, it enormously valuable.
Matt Liotta
President & CEO
Montara Software, Inc.
http://www.montarasoftware.com/
888-408-0900 x901
> -----Original Message-----
> From: Rick Faircloth [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 15, 2003 11:53 AM
> To: CF-Talk
> Subject: RE: RE: How to handle Calendar Scheduling of Recurring
Events?
>
> Hi, Matt.
>
> I think Jeremy is basically taking the same approach I've been
> considering: events are not actually stored as "specific occurrences"
> except in the "events" table. The second table only contains
> "descriptions"
> of recurrence patterns involving events, but not the events
themselves.
> The info in the second table on serves to allow creation of events.
>
> When you say "a properly implemented recurring event pattern should
also
> support one time events" what do you mean, specifically, by "support"?
>
> Rick
>
>
> -----Original Message-----
> From: Matt Liotta [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 15, 2003 8:47 AM
> To: CF-Talk
> Subject: RE: RE: How to handle Calendar Scheduling of Recurring
Events?
>
>
> I agree that you should handle recurring events by storing them as a
> pattern. However, I don't agree that you should store events two
> different ways depending on whether they are recurring or one time. As
I
> see it, a properly implemented recurring event pattern should also
> support one time events.
>
> Matt Liotta
> President & CEO
> Montara Software, Inc.
> http://www.montarasoftware.com/
> 888-408-0900 x901
>
> > -----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
Get the mailserver that powers this list at http://www.coolfusion.com
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
