[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coldsync-hackers] Palm::Datebook question

Andrew Arensburger wrote:

On Mon, Nov 03, 2003 at 09:35:56PM +0000, Marco van Beek wrote:


HI,

Can anyone tell me what value is set in

         $record->{repeat}{end_day}
         $record->{repeat}{end_month}
         $record->{repeat}{end_year}

if there is no end date set.



	Looking at the output of 'pdbdump' on my DatebookDB.pdb, and
at the source, it looks as if the {end_day}, {end_month}, and
{end_year} keys aren't set.
	When writing, Palm::Datebook only checks whether {end_day} is
set; it assumes that if that's set, then {end_month} and {end_year}
are also set.



I have found where my 1920 date was coming from (it was actually getting created in the dump, and then causing the {repeat}{end_year} key to be created).

However, simply clearing the key does not seem to clear the problem. Looking at the conduit log file, it would appear that on every fetch, it tries to delete the key again, which possibly means it is being recreated by the default sync conduit.

Trying to clear the data by entering blank data doesn't seem to fix the problem either. It also doesn't appear to be an issue with records that have repeats other than yearly.

By changing a date to a "real" end date, the record springs back to life. When trying to set it back to undated,, setting the fields with an empty value doesn't work. The record disappears again. Resetting the record with a valid end date made the record re-appear, so I tried writing a 0 to the fields instead. That didn't work. I reset the record again, and tried deleting the field again, knowing this time all three fields (day, month, year) would be defined. This worked.

I guess, therefore, that there is some logic going on in the sync conduit that because it only checks to see if {end_day} is set, none of the other values are written to.

Anyway, we have learnt two things. One, deleting the keys works for the {repeat}{end-xxx} fields, and the logic in the Palm::Datebook would be better if if checked all three fields, and maybe forced all three to exist if one of them does, and maybe force/check for valid data in there as well.

Anyway, I am going to re-write my logic to check to see if {repeat}{end-day} exists, and to delete all three fields at once if it does.

Thanks for the pointers,

Regards,

Marco.


This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.