565602 - Lightning 1.1a1pre does not display calendar data of local.sqlite from Sunbird

Status: RESOLVED INVALID

(Calendar :: General, defect)

Description

[Sven Grull]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100510 Lightning/1.1a1pre SeaMonkey/2.1a1pre
Build Identifier: 

Lightning 1.1a1pre 20100512 does not display local.sqlite from Sunbird 20100510.
Usually I copy my local.sqlite from the Sunbird profile directory to the SeaMonkey/Thunderbird profile directory to get access to my calendar data with SeaMonkey. This worked without problems until approx. mid of April. Now the the calendar isn't displayed anymore in SeaMonkey. local.sqlite gets modified when starting Lightning, copying this version back to Sunbird results in an incompatibly error from the version check at Sunbird start. 
It seems that database structure of local.sqlite for Lightning was amended but old database structures are not loaded anymore.

Reproducible: Always

Comment 1

[Philipp Kewisch [:Fallen][☁️📆]]

Please enable calendar.debug.log and calendar.debug.log.verbose in the advanced config editor (Options > Advanced > General > Config Editor) and check your error console for messages.

We had bug 479867 and a regression (bug 561735) on this, but I thought this was fixed.

Try this:

* Enable debugging
* Upgrade your local.sqlite to the latest database version
* Check error console
* Restart (needed!)
* Check your calendars to make sure their url is moz-storage-calendar://

Also, please check your other storage calendars, it may be that if you had a broken profile that got fixed by the regression bug that your events moved to a different calendar.

Comment 2

[Sven Grull]

(In reply to comment #1)
> Try this:
> 
> * Enable debugging
> * Upgrade your local.sqlite to the latest database version
> * Check error console

Update to v19 is done.

> * Restart (needed!)
> * Check your calendars to make sure their url is moz-storage-calendar://

This url is displayed in the calendar properties.

> Also, please check your other storage calendars, it may be that if you had a
> broken profile that got fixed by the regression bug that your events moved to a
> different calendar.

My second calendar is a holiday calendar http://www.mozilla.org/projects/calendar/caldata/GermanHolidays.ics 
So I have no write access to this calendar.


Error console output:

Error: this.mPanelContainer is null
Source File: chrome://navigator/content/tabbrowser.xml
Line: 2484

Warning: assignment to undeclared variable box
Source File: chrome://calendar/content/calendar-month-view.xml
Line: 937

[calAlarmService] starting...

Warning: reference to undefined property categoryManagement.prototype
Source File: chrome://calendar/content/calendar-views.js
Line: 538

Warning: reference to undefined property this.tree.view
Source File: chrome://calendar/content/calendar-unifinder.js
Line: 677

After importing a Sunbird exported .ics these calendar data is shown.

Comment 3

[Sven Grull]

(In reply to comment #1)
> Also, please check your other storage calendars, it may be that if you had a
> broken profile that got fixed by the regression bug that your events moved to a
> different calendar.

It seems that this bug could be the result of the mentioned regression bug.
I copied all "calendar.registry.*" entries from my Sunbird prefs.js to my SeaMonkey prefs.js and once again copied my v18 local.sqlite to SeaMonkey. 
This triggered a new migration and the calendar is now visible. The output in the error console this time is more detailed as when I only copied local.sqlite.

Comment 4

[Sven Grull]

But if I copy the v18 local.sqlite from Sunbird to SeaMonkey once the migration in prefs.js is done as mentioned in comment #3 the calendar is not displayed again.

Comment 5

[Stefan Sitter [:ssitter]]

Please keep in mind that recent Sunbird nightly builds are identical to the 1.0b1 release. Only Lightning is being developed further and contain changes to the database format. Therefore the local.sqlite files are incompatible and should not be copied to each other. The upgrade from old Sunbird format to new Lightning format probably never gets triggered because its based on the version in storage.sdb. I suggest to resolve this bug as invalid because copying files between different versions is no supported workflow.

Comment 6

[Sven Grull]

(In reply to comment #5)
> Please keep in mind that recent Sunbird nightly builds are identical to the
> 1.0b1 release. Only Lightning is being developed further and contain changes
> to the database format. 

As the database scheme v18 is used by Lightning and Sunbird I think there has to be a way to update v18 to v19 anyway independent which application created the file.

> Therefore the local.sqlite files are incompatible and should not be copied
> to each other.

So using an old backup with a newer version of Lightning also won't work.

> The upgrade from old Sunbird format to new Lightning format probably never
> gets triggered because its based on the version in storage.sdb.

Deleting storage.sdb in Sunbird profile has no negative effect on the start-up of Sunbird. The file gets rebuild every time at start. So from my view the scheme information seems to be stored in local.sqlite.

> I suggest to resolve this bug as invalid because copying files
> between different versions is no supported workflow.

I admit that this is not an usual way. But in case of backups (with the same application) it might be more possible.

Comment 7

[Philipp Kewisch [:Fallen][☁️📆]]

(In reply to comment #6)
> (In reply to comment #5)
> > Please keep in mind that recent Sunbird nightly builds are identical to the
> > 1.0b1 release. Only Lightning is being developed further and contain changes
> > to the database format. 
> 
> As the database scheme v18 is used by Lightning and Sunbird I think there has
> to be a way to update v18 to v19 anyway independent which application created
> the file.
Sunbird has been deprecated, see http://weblogs.mozillazine.org/calendar/2009/02/calendar_project_at_a_critical.html

The latest Sunbird nightly/release does not contain the same patches that the latest Lighting nightly contains. Therefore we can't upgrade to v19 with Sunbird.

> > I suggest to resolve this bug as invalid because copying files
> > between different versions is no supported workflow.
> 
> I admit that this is not an usual way. But in case of backups (with the same
> application) it might be more possible.

I'm going to close this bug invalid for now, you should be able to restore backups of Lightning (together with the prefs.js!) withough problems. If not, please file a new Lightning Only bug.