After running Zulu successful for some time now, we run into this problem after a restart of the Mac mini that is hosting the Data.
We're using the ZuluSampleData file integrated as an external file into our solution

iCal reports the following:
The server responded with
“500”
to operation CalDAVAccountRefreshQueueableOperation.

There are 2 types of error messages i can see in the FileMaker Server 12 Error log

localhost 127.0.0.1 Zulu XML 105 496 "/fmi/xml/FMPXMLRESULT.xml?-db=ZuluSampleData&-lay=ProscNoSuchTable&-view"

localhost 127.0.0.1 Zulu XML 102 496 "/fmi/xml/FMPXMLRESULT.xml?-db=ZuluSampleData&-lay=ZuluSampleEvents&zulu_DELETED.op=neq&zulu_DELETED=1&team=horren&-max=all&-find"

Publishing from the ZuluSampleData file is still successful.

Any suggestions?

very kind regards,
Danny.

BTW: i'm running version 1.315.1 of Zulu on a Mac mini running FileMaker Server 12 on Mac OS X v 10.7.4

Hi Danny,

Hope all is well. 105 is layout is missing and 102 is field is missing.

Zulu first looks for the ZuluCalendarList layout. That name is specific and if it's got a different name, then that will throw the 105 error.

After it finds the ZuluCalendarList layout it loops through the calendarlist records and goes to find the corresponding events according to layout name and filters (if any). So, if any calendarlist record is referencing a layout name that's not there, then that will throw the 500 error as well. This also includes any calendarlist records with no layout specified.

The 102 error is probably just the result of the 105 error, so I would focus on making sure the layout names are correct.

A brute force approach I often take is to delete all the calendarlist records and republish, and then duplicate and add filters if needed. This should ensure that the data in the calendarlist records is correct and layout and fields references are current.

Let me know if that helps. If you're still having trouble then please send me your log from the zulu/admin page. There's a link there and the log will come right to me.

Thanks
-Jason

Thanks for your feedback Jason.
I tried all the actions you proposed but to no avail.
As i'm still in development phase i could delete all my test data, so i did and that solved my issue.
(If it is the combination that solved this issue, we will never know, i can not reproduce, well, i could if i would go back to a backup, but as i tried this remote, it's not that obvious)
Thanks for your support Jason.
(And keep up the good work with this fantastic product)

Unfortunately the issue came back very fast. i'm investigating this today. More info later today.

OK, here some more detailed feedback. The 105/102 error has disappeared now.

The problem was in the filtering, although i used the correct names of the 2 fields i wanted to use for filtering.
i had to add those 2 fields on the Filtering tab of the Field Mapping layout in the file.

Before the reported issue, I tested my whole solution and was based on a two step planning.
First i assign an event to a product group, filtering on a field called "team".
in the second phase, i assign that same event to the person, filtering on a field called "initials".
This way i have 2 calendars looking at the same event but using a different filtering field and values.
This was very easy to do from within iCal, even selecting multiple events and assigning the all at once to another calendar. ( Very similar to assigning work to be done to people )

Now i can no longer "change calendar", because the event will be marked as "deleted" and not get the proper filtervalue, although the documentation on your wikipages explains this differently http://www.seedcode.com/pmwiki/pmwiki.php?n=Zulu.SwitchingCalendars

Any suggestions how i can streamline my workflow to get this 2 step planning working again?

very kind regards,
Danny.

H Danny,

Right, we do have a trick for maintaining multiple filters and having them survive a calendar change. We use a multi-line filter here, but the principle is the same.

http://www.youtube.com/watch?v=jfgYnHzakvA

Let me know if that helps.

Cheers!
Jason