To the talented crew at Seed Code, this novice Filemaker Pro developer sends greetings.

I created a database to track Final Exam appointments for the Math Department, based on your free calendar code. It works wonderfully; everyone likes how well it works.

Because of our tracking needs, I had to add a student information table with a variant of the appointment booking form. The modified form uses a portal to look at students. This method of booking allows the staff of click on the student’s name to retrieve the necessary information for appointment, as well as allow the staff to track attendance.

The staff liked it so much, that they want to add more uses. In addition to tracking the Final Exam appointments, the staff would like to track tutoring appointments and workshop appointments. Each of these have slightly different tracking and attendance needs, thus I will need to build different tables. Also, these additional appointments have space limitations – I need to close the appointment once the seats are filled. Again, different space limitations for each appointment.

Another point of consideration is, I need to block “double usesâ€

Hi Joy,

Thanks for your note. I don't know how far you'll be able to get with the free version as some of the things you're talking about - especially the room conflicts - require a very good knowledge of FileMaker in order to implement from scratch. I don't know what your FileMaker background is, of course, so maybe this will be easy for you. This is, as I'm sure you know, why we offer the Pro calendars, but since you can't use them here is what I'd suggest.

- You may want to consider keeping all 3 types of appointments in the same appointments table if you can and distinguishing them by title, color, or by adding a filter to all the calendar relationships so you can see just one type at a time.

- If you can't keep all three types in one table you'll duplicate all the green table occurrences to the right of CalendarDaily and CalendarMonth and repoint these at your new tables. So CalendarDaily would then be related to 3 appointments tables instead of 1. You'd then duplicate the daily layout and swap it's portal to use one of your other 2 appointment types, and do the month layout until you had 3 month layouts, one for each of your appointment tables.

- The room conflicts are just tough. Consider a self-join relationship with your appointments tables using criteria that include the date, time, and room. Then, if there is a match across this relationship you can present a warning to the user that the room is already spoken for. Since all 3 types of appointments use the same room, keeping these in one table means yo u have just one self join to check. With three tables, each would need a self join then a conflict checking relationship to the other two.

I hope that gets you started.

Thank you so much for your note and advice. I'll clone my working copy into a few test versions and see what I can do.

I hope you realize just how much I appreciate your assistance and the caliber of your product. I've grown to trust Seed Code very much over the past several months very much.

Thanks for the kind words Joy; it means a lot.

While I think creating 3 separate files isn't really a bad way to go, I wouldn't literally make "clones", as the calendar file is a bit tricky to recover from a clone (lots of interface records and settings to add). You can likely just delete all records from the appointments table and start from that.

Good luck.