If $sc_Resources isn't being set, it must be because the value in the CalendarInterface::ValueList field doesn't exactly match the name of a value list in the file. Use the Script Debugger and the Data Viewer to monitor the contents of CalendarInterface::ValueList on startup. Maybe that field is empty when the failure occurs?

If $sc_Resources isn't being set, it must be because the value in the CalendarInterface::ValueList field doesn't exactly match the name of a value list in the file. Use the Script Debugger and the Data Viewer to monitor the contents of CalendarInterface::ValueList on startup. Maybe that field is empty when the failure occurs?"

That's not what I am seeing. Calendar interface::ValueList has an appropriate, matching value both when the menus work and when they fail (it can be the same value). The failure is evident upon the first execution of Load Resources ($Sc_Resources is empty and the default resource list loads into $$Sc_ResourceList instead), which as you know is very early in the startup.

Stranger still, I can launch the Calendar 10 times (or whatever) and the partitioning menu works, a fact that is evident upon watching the first call to Load Resources. Then on the next 4 launches (or whatever) it doesn't. Switching from Filemaker Pro 11 to Filemaker Pro Advanced 11 (or the reverse) seems to make a string of failures more likely, as does logging out of my Mac user, then back in. That suggests that successes depend upon some sort of application caching which is lost with these switches. Given how little happens at startup before Load Resources is called (and the problem is apparent the first time it is called), and given that I otherwise change NOTHING between launches, it's all very strange and frustrating.

One more clue, but I'm not sure to what. For many users I have the Calendar launch directly to the Schedule tab of the Calendar layout (that's where they're going to live, as they are scheduling appointments for several mental health clinicians.) (I've removed your original Calendar Home layout). Other users are directed to the Week tab (the calendar is filtered to show just their events. They'll live there, scheduling their own clients.) The decision to go one direction or the other is the last action performed in Upon Opening, and therefore occurs after the first call to Load Resources. IOW, for some users the calendar runs Perform Script ["Go to Calendar Tab (Tab Name)";Parameter: Calendar Resource Scheduling - Vertical"], while for others it runs Perform Script ["Go to Week"]

For those users destined for the Schedule tab, and ONLY on those occasions the resource partitioning menu fails to operate, there is also a very long delay (complete with spinning OS X beachball) before the calendar displays the schedule and becomes operative - about 10 or more additional seconds. When that happens, on inspection I find that the Insert into Calendar { Column } script hangs for some time on the Set Variable step just below the comment, "Get Column: Day of Week, Resource (Vertical) or Time (Horizontal). There the variable $$sc_Column is set with a complex calc that appears to hang (<- just guessing).

At any rate, it appears that whatever is causing the menus to fail also causes a long delay in taking the first trip to the Schedule tab. But only sometimes!!

BTW, I'm using data separation for performance. The calendar interface resides on user laptops, while the Events table and an extensive contact tables (more than 5000 entries) reside in a file that lives on Filemaker Pro Server based hosting service (Datatrium, for now).

I really like this mod, and will probably have my users relaunch to get it to work, but that seems pretty lame!

That does seem strange. If you have FileMaker Advanced, put a stop in that script, before that local variable gets set. Then run to that point as many times as you have to until the failure occurs, using the Data Viewer to monitor the contents of that variable.

I know this kind of troubleshooting can be frustrating, but the good news is that there is probably a perfectly logical explanation for what you're seeing; you just haven't found it yet. I've only seen truly irrational behavior in FileMaker files a handful of times in almost 20 years, and that's usually means the file is corrupted. I certainly hope that's not the case with your file.

Let me know what you find.

Here is a new and somewhat foreboding datapoint:

I placed the statement "Set Variable [$Sc_Resources; Value:ValueListItems ( Get ( Filename ) ; CalendarInterface::ValueList )] at the beginning of the Upon Opening script - so that it is the absolutely the FIRST statement executed upon starting the calendar. Then I set up a Show Custom Dialog to immediately display both CalendarInterface::ValueList and $sc_Resources. (I left this statement in Load Resources as well, of course, as $Sc_Resources is a local variable).

More often than not $Sc_Resources is initialized by the statement. Sometimes not - even though CalendarInterface::ValueList contains an appropriate value. On those occasions the Resource Partition fails and the start up delayed by about 10-15 seconds, followed by a "beep" when it at last loads everything.

So "Set Variable [$Sc_Resources; Value:ValueListItems ( Get ( Filename ) " sometimes fails when it the FIRST statement executed by the Calendar. So it can't be anything I've done!!

By the way, in the instance of failures, Get ( Filename ) returns the name "Calendar," as it should.

If this points to file corruption, what should I do? (A consistency check shows no problems, and I've already saved the file as a compacted copy.)

I would also note that the problem is evident before any statements have executed, any layouts loaded (an empty window opens while the startup is underway, before those first two steps execute - so what can be corrupted? The problem is evident before I traverse any elements of the calendar!

One thing that happens prior to any script steps executing is the establishment of relationships between my interface front end and my hosted data file. If I deny the calendar access to that file (by turning off my wifi) I can no longer duplicate the problem. Now I'm wondering if the problem is not in that data file, which contains the Events and Contacts tables along with some further supportive tables.

The history of that file is as follows: I originally built the Calendar as a single file containing all tables and the interface, with the idea that it would all reside on the host. But the performance hit was just too much, so I implemented a data separation model. What I did was Empty a copy of the Calendar of the data tables to serve as my front end, then point it to the tables in the old calendar, still on the host. So the Data file actually has an older version of the calendar interface, along with older versions of all the layouts, fields etc. So I think my next step is to pull that down and clean it up.

Hard to say what might be going on here. If you can describe exactly how I can reproduce the problem, send your file to [email protected] and I'll have a look.

Wow. I figured it out.

The problem was that my hosted data file, which contains my main Events and Contacts tables, had the same file name as my local Calendar front end.

That happened because the data file had formerly been a copy of the complete calendar, interface and all. When I broke out the interface into a separate file I left a copy of the original on the host and treated it as an external data source, without actually changing its name. That seemed to work fine. My intention was to return and clean it up.

But that apparently confused the "Set Variable [ $sc_Resources; Value:ValueListItems ( "Calendar" ; CalendarInterface::ValueList ) ]" script step, as the step finds the file by file name before retrieving the value list. I'm guessing that sometimes it used my local version and found the value lists, sometimes the hosted file, which didn't contain those lists. It wasn't quite random - the choice would run in streaks with repeated launchings.

The main clue was the fact that the resource menu worked fine when my front end was isolated from the data file.

Nice sleuthing! I'm glad you got it figured out. Thanks for letting us know.