I guess I'm not sure about the nuts and bolts. How does every other calendar out there do it. Nearly everything I have seen either on line or as a desktop application allows for "All Day" events.

Take a look at the Google calendar as it allows for all day events as does msn and yahoo. They both allow for all day events that span multiple days and recurrance. To be a really viable calendaring solution it really must support All Day events.

Hi Bill.  I will compromise and add the "Return" on the Detailed Event View and the MyEnrollments.  Showing the Detailed View on the same page as the Month is not an option.  Think "MS Outlook" and every other full-fledged Calendar/Event app...most do not show multiple views simultaneously.  Also, this effects performance on the page...also, this would take time to re-code.  Putting the "Return" back on all non-view forms for now should solve the issue...are you OK with that?

Alan,

I drew the database diagram of this Module and here are my findings.  Many relationships are missing and some normalization should also take place.

1. Table Events
   • Importance. Leave it although it could use a EventsImportances lookup table.
   • RepeatType.  (It is a hardcoded, closed list of values).  Limit to Varchar(2) or (1), or use EventsTypeTable. Alternately,  is it much rework to use an iCal format in a single column?
   • Every. See RepeatType
   • Period. See RepeatType.
   • Reminder. Opportunity to add an EventsReminders lookup table of messages.
   • Notify. See Reminder
   • CreatedBy.  It holds a UserID from Users,  Make integer, Add FK to Users.UserID
   • PortalID. Not required it is accessible through the ModuleID FK to the Modules table.
   • Location. Rename LocationId, Add FK to EventsLocations
   • Category. Rename CategoryID, Add FK to EventsCategories
   • MaxEnrolment. Currently accepts negative number.  Use Validation in code and/or db constraint.
   • EnrollRoleID. A Roles.RoleID.  Make Integer.  Add FK to Roles.RoleID. (BUG:  Currently not update by code).
   • EnrollType.  2 hardcoded values (FREE,PAID). Replace with HasEnrollFee, or eliminate to adapt logic on a non 0 value in EnrollFee.
   • ImageURL. Should use same pattern as the rest of DNN : (2 cbo, pick root, pick or upload file, save filename in ImageFile column). 
   • ImageType. Not necessary, base code logic on the presence of HTTP:// or FileID in field if we can use external image.
2. EventsCategory
   • Rename to EventsCategories, the naming pattern for most core modules although not strictly followed.
3. EvenstMaster
   • MasterID.
   • Module ID. Suggest rename to MasterModuleID
   • SubEventID. Add FK to ModuleID. Suggest rename to SubEventModuleID
4. EventsNofication
   • PortalAlliasID : Add FK.
5. EventsPPErrorLog
   • Add FKs where requiered.
6. EventsSignups
   • Add FKs

Most suggestions are to improve the database design and enforce data integrity which normally a good thing to have.  Some are recommendations you might not want to put in place.

I understand many of these changes will have an impact on the stored procs and even the code.  I'm willing to help put them in place.  If you want my help, let me know, you have my email on your personal site for user francoir.

HTH.

Francois