Hi, I was wondering if anyone else is having problems with their ical subscription to Seedcode? The problem I'm having is if I make a change on the appointment, like move it a day earlier for example, the ical subscription shows the appointment for the original date instead of the new one. I've tried refreshing multiple times but it doesn't make a difference.

What am I doing wrong?

Hey Ken,

Not sure what might be going wrong, but I haven't had that problem. One thing I'd try for troubleshooting is opening the subscription URL in Firefox- since that browser can't talk to iCal you can save the resulting xml as a text file and see if there are any strange things there. From what you describe I doubt the problem is there. Silly as it sounds, the first thing I'd check is that I'm subscribing to the same database I'm editing and not an "imported" version of the same calendar.

Wish I had some clear direction for you.

I have found that using the XLST template provided by myFMButler there is an issue were ical files do not update when subscribed to with iCal (Leopard). The exact same file works fine in Tiger but in Leopard if you change data in an event (ie times, notes, etc...) the files does not update. If you change the date, add or remove an event it seems to update fine.

Maybe you can shed some light on why this is happening.

Hi. I'm using leopard and havent seen this- of course maybe i judt haven't noticed. (i'll double check today)

Does making your appointments calc unstored help?

Double checked to make sure that calculations were unstored. They were unstored and the problem is there.

I am duplicating the issue on multiple computers. I have an Intel Mac and PowerMac running Leopard (10.5.1) the problem exists on both.

I also have two computers running Tiger and the problem does not exist on either of them.

I have also duplicated the problem withtwo different FileMaker files. The sample file from myfmbutler website (unmodified) and my own calendar solution file. The problem occurs on both.

Hey Partrick,

Just got back to the office and checked a couple calendars. If I change the appointment title or time in FileMaker, commit the record, and then right click the subscribed calendar in iCal and select "refresh", it changes without fail. This is on a Mac running 10.5.1 and iCal 3.0.1.

Unfortunately I'm not sure why yours wouldn't refresh.

Could it be that you've imported these calendars instead of subscribing to them? If they're subscribed they'll be listed under "Subscriptions" and present a "refresh" option when you right click on them. If they're imported then right clicking on them offers "refresh all" instead.

I'm definitely subscribed. They show up under the subscribed list and some changes - such as adding an event or changing the date - will refresh fine.

Other changes - such as changing the time or notes - don't show up unless you delete the calendar and re- subscribe.

It's also definitely related to Leopard - my Tiger machines work fine. I wonder if there are cache files somewhere that are causing the issue.

I found something that seems to be the cause of problems.

The events are using the start and end times that are stored in a related table. When I change times, iCal (Leopard) does not pick up on the changes. iCal (Tiger) works fine.

If I change the start and end times to fields located in the event table, Leopard works fine. However, they have to be Time fields not calculation fields calling data from a related table. If I reference times from the related table iCal won't pick up on the changes.

Interesting. Are the notes also in a related table? I ask because you mentioned that changing the notes on an item doesn't cause it up update in Leopard and I don't see how having the times in a related table would affect that. I might suggest comparing the .ics generated in each case (local time fields vs related time fields) to see if there is any difference in what the server is returning. (I usually open the subscribe link in Firefox to see the raw .ics file)

I had submitted a support ticket to myFMButler since the original XSLT template file came from them. They did respond to me yesterday and said they had recently discovered the glitch I was talking about but that they did not have a solution at that time.

The problem is related to changing data in fields and related fields and iCal (Leopard). For whatever reason iCal (Lepoard) does not update the changes even though raw file generated contains the changes and those same changes are updated in iCal (Tiger).

I spent sometime troubleshooting and this is the workaround I came up with. I did all testing using the XSLT template provided on myFMBulter website.

1) I changed the fields vcal_creation_date and vcal_creation_time to auto enter Modification Date and Time instead of Creation Date and Time. This causes the field vcal_creation_date_c to change everytime you make a change to the record.
2) This immediately caused any record that I modified to update properly in iCal (Leopard)
3) It still wouldn't update properly if I changed a field in a related record because those fields don't trigger a change in the Modification Date and Time in the original record.
4) I set up ZippScript plugin to run a simple script that updated the vcal_creation_time field ( now a modification time) every time I exit a related field on my event layout.
5) This updates the vcal_creation_time field and by default the vcal_creation_date_c field. iCal Leopard then properly displays the changes in iCal.
6) If the field vcal_creation_date_c does not change, then iCal (Leopard) ignores any changes to the event even though they are in the raw file.

I'm not sure how vcal_creation_time and vcal_creation_date_c are used in the XSL file but iCal Leopard definitely seems to be checking one or both them and only updating an event if it sees a change.

I'm also not sure if I'm screwing something else up by changing the fields from creation values to modification values. In my testing, everything seems to work fine and Tiger functionality was not affected by either change and continued to work normally.

Very cool Patrick; thanks for posting these details!