Just wanted to throw my hat in this pile.

• Various servers: Win2K8 & Mac OS 10.6
• Hit or miss. When it hits, I friggin' love it. When it misses (which is unfortunately more frequent):
  
  1. All respond correctly to John's (brilliant, thanks, forgot about that one) suggestion to use the -dbnames query
  2. All get a Filemaker generated "internal server error" page when clicking on the .ics (read only subscription) link (I know it's a FileMaker error page because it mentions visiting FileMaker as a solution)
  3. All respond with the error mentioned above in iCal
  4. All get an error either mentioning the Google account or the FM account when attempting to sync with Google
  5. All respond with "There has been an error reading data for calendar: MyCalendar. However, this error is believed to be minor, so the program will attempt to continue. Error code: DAV_NOT_DAV. Description: The resource at http://myserver.com/zulu/calendars/myFi ... OFNUMBERS/ is either not a DAV collection or not available." in Sunbird. This is accompanied by another message, which starts the same way, only the error code is READ_FAILED, with no description.

Hoping there's a resolution - LOVING the idea and promise of this product.
-Andy Frazier

...forgot to mention...checked & rechecked that all accounts have XML priv enabled, and this is on a mix of FMS 10 and FMS 11 servers (including FMSA). Fresh installs and very long-in-the-tooth ones.

Hey Andy,

Thanks for your post. I moved this to it's own topic so it gets the attention it deserves.

When Zulu (or iCal) throws an error, there is a reason, and I'd like to take the time to find those reasons for you so you can get all your servers happy with Zulu. The reasons are usually in access privileges, or sometimes in data (if you have events with end times before start times, for example).

For starters, if -dbnames looks good that means the WPE is working, and if Zulu is our of demo mode then errors are cause by Zulu not "seeing" your database, it's layouts, or its fields. If "Publish" worked, then it is seeing the database, so I'd focus on the access privileges when clicking on an .ics file (taking one file, on one server at a time to troubleshoot this).

Looking forward to working through this with you.

- John

Hi John...

OK - User is [Full Access], fmxml enabled. Here's a shot of the page I get when clicking the .ics link:


Thanks,
Andy

Just an update...on this server I just uploaded and published your sample file and it worked...now looking at some more basic stuff like maybe missing data in key fields, or maybe mismatched datatypes...

More interesting stuff...I think it might have been a data issue. In this set of 29 calendars, based on 2 tables, 1 of which was split into 2 layouts (with different filter keys), I noticed each time I tried to publish, not all the "subsets" (layouts) were getting "zulu_properties" filled in by the engine - not sure if it was the layout name, filterkey - whatever....but I went and redefined and cleaned them all up, and it appears to be working...it's a MASSIVE calendar (those 2 base tables contain about 100K event records each - but of course filtering to 60 days [30 on either side] helps), so it's taking a while to load...but it's actually loading on iPad, Google, Sunbird, and iCal right now...thanks for the help....

Very cool Andy! Congrats on teasing that out. Let us know if anything else comes up.

- John

ALMOST time for the champagne....almost. Everything but Google works beautifully. When doing "Sync NOW" and/or "Save Changes" on the Google sync page, after about a million years (5-10 minutes, but these days, what's the difference?), I get what appears to be an Apache-generated internal error page:

Internal error

Return to home page


Never quite got that far on the big server from last night, I posted those messages while waiting, but after about 15 minutes it just timed out. But today I was working on one of the smaller ones so I got to see the end result. Ideas?

Hi Andy,

I'm not sure how many events you are trying to sync with Google, but it may be timing out as Google doesn't respect the date range gates that iCal does. I'd try to limit the number you are syncing by putting a 1 in the zulu_DELETED field for any you don't want synced, I'm thinking anything in the past.

If that doesn't resolve it, then I'd do a GoogleReset and start fresh.

http://www.seedcode.com/pmwiki/pmwiki.p ... oogleReset

In this case I'd still try to limit the number with the zulu_DELETED field as well.

Let us know how you make out!

Well...progress...it's not timing out. I took those steps to limit the data, that still timed out, so I followed the instructions on Google Reset. 2 oddities there:

--There was no ZuluSync directory in windows\system32\config\systemprofile (verrry interesting...maybe a permissions problem in the systemprofile directory?)
--After redefining the FM/Google account pairing, and replacing all the calendar IDs, I got this response when trying to Sync NOW:

Sync failed: java.lang.RuntimeException: Failure while getting list of changes from GoogleCalendarNode:[email protected]: java.lang.IllegalStateException: The ResultSet is not positioned on a valid row.

Hi Andy,

So that's the error we see when we try and do a Google Reset, but the sync folder hasn't been deleted. Just to confirm, the windows\system32\config\systemprofile path is the example one in our docs, yours could be different, and you want to get that from the bottom of the Zulu/Admin Page.

If you can't find the folder, we're thinking there is something wrong with the OS that may require a reinstall.

Let us know.

Just a quick addition Andy. The Zulu Sync folder is only created *after* the first successful sync with Google. You should have synced our Sample file as part of troubleshooting, so it should be there, but if you haven't had any successful syncs then it would be normal not to have it.

So have you had any successful syncs with Google?

Looks like it may have been all about the volume. After following your suggestions and severely limiting the # of events it was allowed to show, it still took a bit, but it eventually worked. In this case eliminating the past entirely would have been a little confusing to users, so I ended up going 2 days in the past and 14 days into the future, making it so it only had to sync a few hundred events. Then I wrote a server-side script to run nightly, marking that "deleted" field on anything older than whatever's set for the "days in past." This had the added benefit of making sync with iThings a whole lot faster.

Thanks!

BTW - got tired of having to guess what the color would actually look like, so here's a little custom function to use as the source in a webviewer, when setting up your calendars. It'll take anything that css will accept as a color and set it as the background of the wv:

Swatch(color)

Code: Select all

"data:text/html,
<body bgcolor=\"#"&color&"\"
LeftMargin=\"0\" RightMargin=\"0\" TopMargin=\"0\"
\"border=\"0\" style=\"border:0;scrolling:no;background:"&color&";\">
</body>"

That's great Andy. We've got some documentation on limiting the number of events, but we should probably have them be part of the Google Set Up steps.

Thanks for the custom function, I just added it to my test ZuluCalendarList layout and it works great...very nice touch!

-Jason