OK - Keeping with the theme of bringing a client to SeedCode Complete 3.11 in FMP 12 from their use of a customized previous version of the older software.

If I understand correctly, the old version used Appointments (base) and it TOs to show what are now called Events.

In the older system, many different types of appointments could be accommodated by adding their entity-specific fields to the Appointments table. So a training session might use the standard Appointments fields to include a course/event name, date, time, etc., and then the developer could add separate fields for "previous course requirements" and "grade." Or, a social incident could use standard fields, but add "seriousness" and "reported to" fields to the Appointments table to log that data. Ultimately, different kinds of incidents could be handled in one table, and filtered by "type" (ApptType_kf), which was also used to color-code the appointments.

In the new system, it seems that the Sources mapping provides for different "types" of events, for filtering and (optionally) for color-coding. We've already moved many fields from the old Appointments table to the new Events table, but as I progress, I'm wondering if that's the best way. For some items, for instance, it could be nice to show them in the navigation bar, have special form and list layouts, etc., even though I know it would mean finding sub-sets of data and importing them separately when it's time for that. Separate tables may also make it easier to manage varying numbers of contact links (e.g., an appointment event may just need a single contact, or a second "appointment WITH" contact key; whereas a training may involve multiple teachers AND multiple students), but I'm not sure.

Question 1: Am I understanding all this correctly?

Question(s) 2: What are the advantages and disadvantages of incorporating these different types of data into events, versus creating separate tables for them? Is there a "key deciding factor" to go in one direction versus the other - for a given table, or for the solution overall? Any gotchas to watch out for?

TIA,
d~

Hi Debi,

Thanks for posting this, good stuff!

Right, you're understanding this correctly.

With 3.11 I think you're really better off keeping them in one table with flags rather than going to multiple sources/tables. Performance does take a hit with multiple sources, as we need to perform finds for each source and then sort all the combined results. Adding fields to tables can affect performance as well, particularly over the WAN, but I think that you'll take a bigger hit with the sources.

Additionally, there's a lot of additional abstraction that will need to be added to the scripts to have each source behave the same with repeating events, etc.

hth,
Jason

Jason - Thanks for your ongoing advice and help! d~

You got it Debi
and thank you for posting this great stuff here!