SeedCode Support Forum

All of a sudden iCal is giving me this message

The request for account “xxx.org” failed.

The server responded with
“500”
to operation CalDAVAccountRefreshQueueableOperation.

I have checked with Zulu admin

✓ Zulu is communicating successfully with Web Publishing Engine running on localhost (ssl: false)

This appears to be OK

And filemaker server claims that all systems are normal.

What could the problem be?

Hi Geoff,

If all the connectivity tests look good, then I would be suspicious of some new data that's been added that's causing Zulu to hang up. Things like an end date with no start date, end date before the start date, etc. can cause the whole refresh/stream to fail. These are the most common ones we see, but the URL field is also touchy, so if it has spaces or returns in it, or other things that would prevent it from being a valid, than iCal doesn't like that either.

hth,
Jason

Hi,

Hmm. Your comments made me realize that the SampleEvents table doesn't have creation date and modified date fields which would make the search for the culprit a bit easier.

I have been through all of what I think have been recent modifications, and found several instances of end times that preceded start times and have fixed them. However the problem remains. Do you have any search formulas to help find the culprit.

I have just created a calculation field that does this

Case (DateEnd = "" ;"";
TimeEnd = "" ;"";
DateStart > DateEnd or
TimeStart > TimeEnd ; "The culprit is here"; "" )

I have modified all the events that came up positive here, so that there are none left. As for the URL field, there aren't any fields with any data and yet the problem prevails. What can I do now ? Are there any other fields that could be responsible ?

Hi Geoff,

We do have the zulu_CreationTimestamp and zulu_ModificationTimestamp fields in the table, so those could help. Those are the most common data issues I run into. Other things I can think of are: duplicate primary keys, no primary key, a leading space in front of the primary key (value, not field name).

The Catalina Log can sometimes help identify the problem as well. But, my approach is to delete all events except for one that I know is right to confirm that it is an event issue. I then start adding them back in to the table and refreshing until the error occurs, and then narrow it down that way.

The other thing to check is the calendarlist records, I ran into a case the other day where someone had accidentally created a blank one and that was causing trouble.

Let me know if that helps!
Jason

Hi Jason,

Yes I didn't think of zulu_CreationTimestamp and zulu_ModificationTimestamp fields. They do help. But for the moment the problem continues and is getting quite frustrating

So I found one duplicate primary key, deleted it. No better.
I didn't find any empty primary key fields or any beginning with a space.

I deleted all records except one that I am pretty certain should not present a problem, and iCal still gave the same error message. Can we assume that it is not an event issue? What else ?

Ouf ! I think I found the problem. I went back to Zulu admin and found two problems. Firstly that I had left "contacts" checked under "FileMaker & Google Accounts to Synchronize" when I have never succeeded in syncing my contacts. And when I tried to "sync now" I got an error message. A few days ago I was rethinking my whole field naming concept throughout all my FM files and changed the primary key field name in Seeedcodecalendar without republishing. I think the error came from here. What is weird though is that the problem in iCal predated this intervention, and checking that everything was OK in Zulu administration was the first thing I did.

Hi Geoff,

Great, thanks for the follow up!

Right, any changes to zulu related field names or mapping is when you need to republish, as that info is stored in the zulu_Properties field and needs to be updated with changes.

The Contact Sync does run after the Calendar one and keeps a separate sync folder, so not sure what's going on there. I recall it being a pretty large set of contacts, so syncing just a few to start, making sure that works is where I always start to make sure my schema and field mapping are good, and can limit my troubleshooting efforts to specific records as I add them to the sync.

hth,
Jason