Mailing List Archive

Hi,

> I got an error while upgrading DAViCal to 0.9.9.6-1.
[...]
> DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
> /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
> Database permissions updated.
>
> What went wrong? What do have to do in this situation?

Did you follow this procedure?
http://wiki.davical.org/w/Update-davical-database

HTH,

Vincent
--
Advocatenkantoor Suy, Van Baeveghem & Van Houtte
Brusselsestraat 108
9200 Dendermonde
T +32.52.52.06.05
F +32.52.52.06.46
W http://www.synergylaw.be


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

Hi Vincent,

I did read the wiki. But there is no help for this problem and I hope I
can avoid the roll back of code. The German error message says that the
relation "time_zone" does not exist.

But it seem to me that everything is fine except this one thing with the
time_zone.

I started the database update with -debug option and this is the output:
davical@ubuntu:~$ sudo /usr/share/davical/dba/update-davical-database -debug
[sudo] password for davical:
Using database: davical_dba%@dbi:Pg:dbname=davical
The database is version 8.4 currently at revision 1.2.11.
Looking at patches[0] (1.1.2.sql)
Patch 1.1.2.sql has already been applied.
Looking at patches[1] (1.1.3.sql)
Patch 1.1.3.sql has already been applied.
Looking at patches[2] (1.1.4.sql)
Patch 1.1.4.sql has already been applied.
Looking at patches[3] (1.1.5.sql)
Patch 1.1.5.sql has already been applied.
Looking at patches[4] (1.1.6.sql)
Patch 1.1.6.sql has already been applied.
Looking at patches[5] (1.1.7.sql)
Patch 1.1.7.sql has already been applied.
Looking at patches[6] (1.1.8.sql)
Patch 1.1.8.sql has already been applied.
Looking at patches[7] (1.1.9.sql)
Patch 1.1.9.sql has already been applied.
Looking at patches[8] (1.1.10.sql)
Patch 1.1.10.sql has already been applied.
Looking at patches[9] (1.1.11.sql)
Patch 1.1.11.sql has already been applied.
Looking at patches[10] (1.1.11a.sql)
Patch 1.1.11a.sql has already been applied.
Looking at patches[11] (1.1.12.sql)
Patch 1.1.12.sql has already been applied.
Looking at patches[12] (1.1.12a.sql)
Patch 1.1.12a.sql has already been applied.
Looking at patches[13] (1.2.1.sql)
Patch 1.2.1.sql has already been applied.
Looking at patches[14] (1.2.1a.sql)
Patch 1.2.1a.sql has already been applied.
Looking at patches[15] (1.2.1b.sql)
Patch 1.2.1b.sql has already been applied.
Looking at patches[16] (1.2.2.sql)
Patch 1.2.2.sql has already been applied.
Looking at patches[17] (1.2.3.sql)
Patch 1.2.3.sql has already been applied.
Looking at patches[18] (1.2.3a.sql)
Patch 1.2.3a.sql has already been applied.
Looking at patches[19] (1.2.4.sql)
Patch 1.2.4.sql has already been applied.
Looking at patches[20] (1.2.5.sql)
Patch 1.2.5.sql has already been applied.
Looking at patches[21] (1.2.6.sql)
Patch 1.2.6.sql has already been applied.
Looking at patches[22] (1.2.7.sql)
Patch 1.2.7.sql has already been applied.
Looking at patches[23] (1.2.8.sql)
Patch 1.2.8.sql has already been applied.
Looking at patches[24] (1.2.9.sql)
Patch 1.2.9.sql has already been applied.
Looking at patches[25] (1.2.10.sql)
Patch 1.2.10.sql has already been applied.
Looking at patches[26] (1.2.10a.sql)
Patch 1.2.10a.sql has already been applied.
Looking at patches[27] (1.2.11.sql)
Patch 1.2.11.sql has already been applied.
No patches were applied.
Supported locales updated.
Updated view: dav_principal.sql applied.
CalDAV functions updated.
RRULE functions updated.
GRANT SELECT,INSERT,UPDATE,DELETE on collection to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on caldav_data to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on calendar_item to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on relationship to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on locks to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on property to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on freebusy_ticket to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on usr to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on usr_setting to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on roles to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on role_member to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on session to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on tmp_password to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on group_member to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on principal to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on relationship_type to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on sync_tokens to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on sync_changes to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on grants to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on dav_principal to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on access_ticket to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on dav_binding to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on calendar_alarm to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on calendar_attendee to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_resource to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_adr to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_tel to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_email to
davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on timezones to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on tz_aliases to davical_app
GRANT SELECT,INSERT,UPDATE,DELETE on tz_localnames to davical_app
GRANT SELECT,UPDATE on relationship_type_rt_id_seq to davical_app
GRANT SELECT,UPDATE on dav_id_seq to davical_app
GRANT SELECT,UPDATE on usr_user_no_seq to davical_app
GRANT SELECT,UPDATE on roles_role_no_seq to davical_app
GRANT SELECT,UPDATE on session_session_id_seq to davical_app
GRANT SELECT,UPDATE on principal_type_principal_type_id_seq to davical_app
GRANT SELECT,UPDATE on sync_tokens_sync_token_seq to davical_app
GRANT SELECT,UPDATE on timezones_our_tzno_seq to davical_app
GRANT SELECT,INSERT on time_zone to davical_app
DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
/usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
GRANT SELECT on supported_locales to davical_app
GRANT SELECT on awl_db_revision to davical_app
GRANT SELECT on principal_type to davical_app
Database permissions updated.

Is there a possibility to repair this without a lot of work?
I think that the DAViCal is running well!?

Kind regards
Ingo Belka
----
Stadt Grimmen, Markt 1, 18507 Grimmen
Grimmen - merk würdig schön http://www.grimmen.de
Tel.: +49 38326 47 228 ingo_belka@grimmen.de
Fax : +49 38326 47 255 hauptverwaltung@grimmen.de

Am 27.09.2011 09:31, schrieb Vincent Van Houtte:
> Hi,
>
>> I got an error while upgrading DAViCal to 0.9.9.6-1.
> [...]
>> DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
>> /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
>> Database permissions updated.
>>
>> What went wrong? What do have to do in this situation?
>
> Did you follow this procedure?
> http://wiki.davical.org/w/Update-davical-database
>
> HTH,
>
> Vincent

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

Hi Ingo,

your problem is your php.ini, has nothing to do with davical but php.

put this into your php.ini:
date.timezone = Europe/Berlin

and all is good.
wolfgang

On Tue, Sep 27, 2011 at 03:59:35PM +0200, Ingo Belka wrote:
> Hi Vincent,
>
> I did read the wiki. But there is no help for this problem and I hope I
> can avoid the roll back of code. The German error message says that the
> relation "time_zone" does not exist.
>
> But it seem to me that everything is fine except this one thing with the
> time_zone.
>
> I started the database update with -debug option and this is the output:
> davical@ubuntu:~$ sudo /usr/share/davical/dba/update-davical-database -debug
> [sudo] password for davical:
> Using database: davical_dba%@dbi:Pg:dbname=davical
> The database is version 8.4 currently at revision 1.2.11.
> Looking at patches[0] (1.1.2.sql)
> Patch 1.1.2.sql has already been applied.
> Looking at patches[1] (1.1.3.sql)
> Patch 1.1.3.sql has already been applied.
> Looking at patches[2] (1.1.4.sql)
> Patch 1.1.4.sql has already been applied.
> Looking at patches[3] (1.1.5.sql)
> Patch 1.1.5.sql has already been applied.
> Looking at patches[4] (1.1.6.sql)
> Patch 1.1.6.sql has already been applied.
> Looking at patches[5] (1.1.7.sql)
> Patch 1.1.7.sql has already been applied.
> Looking at patches[6] (1.1.8.sql)
> Patch 1.1.8.sql has already been applied.
> Looking at patches[7] (1.1.9.sql)
> Patch 1.1.9.sql has already been applied.
> Looking at patches[8] (1.1.10.sql)
> Patch 1.1.10.sql has already been applied.
> Looking at patches[9] (1.1.11.sql)
> Patch 1.1.11.sql has already been applied.
> Looking at patches[10] (1.1.11a.sql)
> Patch 1.1.11a.sql has already been applied.
> Looking at patches[11] (1.1.12.sql)
> Patch 1.1.12.sql has already been applied.
> Looking at patches[12] (1.1.12a.sql)
> Patch 1.1.12a.sql has already been applied.
> Looking at patches[13] (1.2.1.sql)
> Patch 1.2.1.sql has already been applied.
> Looking at patches[14] (1.2.1a.sql)
> Patch 1.2.1a.sql has already been applied.
> Looking at patches[15] (1.2.1b.sql)
> Patch 1.2.1b.sql has already been applied.
> Looking at patches[16] (1.2.2.sql)
> Patch 1.2.2.sql has already been applied.
> Looking at patches[17] (1.2.3.sql)
> Patch 1.2.3.sql has already been applied.
> Looking at patches[18] (1.2.3a.sql)
> Patch 1.2.3a.sql has already been applied.
> Looking at patches[19] (1.2.4.sql)
> Patch 1.2.4.sql has already been applied.
> Looking at patches[20] (1.2.5.sql)
> Patch 1.2.5.sql has already been applied.
> Looking at patches[21] (1.2.6.sql)
> Patch 1.2.6.sql has already been applied.
> Looking at patches[22] (1.2.7.sql)
> Patch 1.2.7.sql has already been applied.
> Looking at patches[23] (1.2.8.sql)
> Patch 1.2.8.sql has already been applied.
> Looking at patches[24] (1.2.9.sql)
> Patch 1.2.9.sql has already been applied.
> Looking at patches[25] (1.2.10.sql)
> Patch 1.2.10.sql has already been applied.
> Looking at patches[26] (1.2.10a.sql)
> Patch 1.2.10a.sql has already been applied.
> Looking at patches[27] (1.2.11.sql)
> Patch 1.2.11.sql has already been applied.
> No patches were applied.
> Supported locales updated.
> Updated view: dav_principal.sql applied.
> CalDAV functions updated.
> RRULE functions updated.
> GRANT SELECT,INSERT,UPDATE,DELETE on collection to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on caldav_data to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on calendar_item to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on relationship to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on locks to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on property to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on freebusy_ticket to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on usr to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on usr_setting to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on roles to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on role_member to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on session to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on tmp_password to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on group_member to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on principal to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on relationship_type to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on sync_tokens to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on sync_changes to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on grants to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on dav_principal to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on access_ticket to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on dav_binding to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on calendar_alarm to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on calendar_attendee to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_resource to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_adr to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_tel to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_email to
> davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on timezones to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on tz_aliases to davical_app
> GRANT SELECT,INSERT,UPDATE,DELETE on tz_localnames to davical_app
> GRANT SELECT,UPDATE on relationship_type_rt_id_seq to davical_app
> GRANT SELECT,UPDATE on dav_id_seq to davical_app
> GRANT SELECT,UPDATE on usr_user_no_seq to davical_app
> GRANT SELECT,UPDATE on roles_role_no_seq to davical_app
> GRANT SELECT,UPDATE on session_session_id_seq to davical_app
> GRANT SELECT,UPDATE on principal_type_principal_type_id_seq to davical_app
> GRANT SELECT,UPDATE on sync_tokens_sync_token_seq to davical_app
> GRANT SELECT,UPDATE on timezones_our_tzno_seq to davical_app
> GRANT SELECT,INSERT on time_zone to davical_app
> DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
> /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
> GRANT SELECT on supported_locales to davical_app
> GRANT SELECT on awl_db_revision to davical_app
> GRANT SELECT on principal_type to davical_app
> Database permissions updated.
>
> Is there a possibility to repair this without a lot of work?
> I think that the DAViCal is running well!?
>
> Kind regards
> Ingo Belka
> ----
> Stadt Grimmen, Markt 1, 18507 Grimmen
> Grimmen - merk würdig schön http://www.grimmen.de
> Tel.: +49 38326 47 228 ingo_belka@grimmen.de
> Fax : +49 38326 47 255 hauptverwaltung@grimmen.de
>
> Am 27.09.2011 09:31, schrieb Vincent Van Houtte:
> > Hi,
> >
> >> I got an error while upgrading DAViCal to 0.9.9.6-1.
> > [...]
> >> DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
> >> /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
> >> Database permissions updated.
> >>
> >> What went wrong? What do have to do in this situation?
> >
> > Did you follow this procedure?
> > http://wiki.davical.org/w/Update-davical-database
> >
> > HTH,
> >
> > Vincent
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Davical-general mailing list
> Davical-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/davical-general

--
http://www.wogri.com

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

Hello again,

I put the value in /etc/php5/apache2/php.ini. Then I restarted the
system, but no success. The error left.

Are there any other suggestions/solutions?

Kind regards
Ingo Belka
----
Stadt Grimmen, Markt 1, 18507 Grimmen
Grimmen - merk würdig schön http://www.grimmen.de
Tel.: +49 38326 47 228 ingo_belka@grimmen.de
Fax : +49 38326 47 255 hauptverwaltung@grimmen.de

Am 27.09.2011 16:27, schrieb Wolfgang Hennerbichler:
> Hi Ingo,
>
> your problem is your php.ini, has nothing to do with davical but php.
>
> put this into your php.ini:
> date.timezone = Europe/Berlin
>
> and all is good.
> wolfgang
>
> On Tue, Sep 27, 2011 at 03:59:35PM +0200, Ingo Belka wrote:
>> Hi Vincent,
>>
>> I did read the wiki. But there is no help for this problem and I hope I
>> can avoid the roll back of code. The German error message says that the
>> relation "time_zone" does not exist.
>>
>> But it seem to me that everything is fine except this one thing with the
>> time_zone.
>>
>> I started the database update with -debug option and this is the output:
>> davical@ubuntu:~$ sudo /usr/share/davical/dba/update-davical-database -debug
>> [sudo] password for davical:
>> Using database: davical_dba%@dbi:Pg:dbname=davical
>> The database is version 8.4 currently at revision 1.2.11.
>> Looking at patches[0] (1.1.2.sql)
>> Patch 1.1.2.sql has already been applied.
>> Looking at patches[1] (1.1.3.sql)
>> Patch 1.1.3.sql has already been applied.
>> Looking at patches[2] (1.1.4.sql)
>> Patch 1.1.4.sql has already been applied.
>> Looking at patches[3] (1.1.5.sql)
>> Patch 1.1.5.sql has already been applied.
>> Looking at patches[4] (1.1.6.sql)
>> Patch 1.1.6.sql has already been applied.
>> Looking at patches[5] (1.1.7.sql)
>> Patch 1.1.7.sql has already been applied.
>> Looking at patches[6] (1.1.8.sql)
>> Patch 1.1.8.sql has already been applied.
>> Looking at patches[7] (1.1.9.sql)
>> Patch 1.1.9.sql has already been applied.
>> Looking at patches[8] (1.1.10.sql)
>> Patch 1.1.10.sql has already been applied.
>> Looking at patches[9] (1.1.11.sql)
>> Patch 1.1.11.sql has already been applied.
>> Looking at patches[10] (1.1.11a.sql)
>> Patch 1.1.11a.sql has already been applied.
>> Looking at patches[11] (1.1.12.sql)
>> Patch 1.1.12.sql has already been applied.
>> Looking at patches[12] (1.1.12a.sql)
>> Patch 1.1.12a.sql has already been applied.
>> Looking at patches[13] (1.2.1.sql)
>> Patch 1.2.1.sql has already been applied.
>> Looking at patches[14] (1.2.1a.sql)
>> Patch 1.2.1a.sql has already been applied.
>> Looking at patches[15] (1.2.1b.sql)
>> Patch 1.2.1b.sql has already been applied.
>> Looking at patches[16] (1.2.2.sql)
>> Patch 1.2.2.sql has already been applied.
>> Looking at patches[17] (1.2.3.sql)
>> Patch 1.2.3.sql has already been applied.
>> Looking at patches[18] (1.2.3a.sql)
>> Patch 1.2.3a.sql has already been applied.
>> Looking at patches[19] (1.2.4.sql)
>> Patch 1.2.4.sql has already been applied.
>> Looking at patches[20] (1.2.5.sql)
>> Patch 1.2.5.sql has already been applied.
>> Looking at patches[21] (1.2.6.sql)
>> Patch 1.2.6.sql has already been applied.
>> Looking at patches[22] (1.2.7.sql)
>> Patch 1.2.7.sql has already been applied.
>> Looking at patches[23] (1.2.8.sql)
>> Patch 1.2.8.sql has already been applied.
>> Looking at patches[24] (1.2.9.sql)
>> Patch 1.2.9.sql has already been applied.
>> Looking at patches[25] (1.2.10.sql)
>> Patch 1.2.10.sql has already been applied.
>> Looking at patches[26] (1.2.10a.sql)
>> Patch 1.2.10a.sql has already been applied.
>> Looking at patches[27] (1.2.11.sql)
>> Patch 1.2.11.sql has already been applied.
>> No patches were applied.
>> Supported locales updated.
>> Updated view: dav_principal.sql applied.
>> CalDAV functions updated.
>> RRULE functions updated.
>> GRANT SELECT,INSERT,UPDATE,DELETE on collection to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on caldav_data to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on calendar_item to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on relationship to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on locks to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on property to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on freebusy_ticket to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on usr to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on usr_setting to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on roles to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on role_member to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on session to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on tmp_password to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on group_member to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on principal to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on relationship_type to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on sync_tokens to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on sync_changes to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on grants to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on dav_principal to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on access_ticket to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on dav_binding to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on calendar_alarm to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on calendar_attendee to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_resource to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_adr to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_tel to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_email to
>> davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on timezones to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on tz_aliases to davical_app
>> GRANT SELECT,INSERT,UPDATE,DELETE on tz_localnames to davical_app
>> GRANT SELECT,UPDATE on relationship_type_rt_id_seq to davical_app
>> GRANT SELECT,UPDATE on dav_id_seq to davical_app
>> GRANT SELECT,UPDATE on usr_user_no_seq to davical_app
>> GRANT SELECT,UPDATE on roles_role_no_seq to davical_app
>> GRANT SELECT,UPDATE on session_session_id_seq to davical_app
>> GRANT SELECT,UPDATE on principal_type_principal_type_id_seq to davical_app
>> GRANT SELECT,UPDATE on sync_tokens_sync_token_seq to davical_app
>> GRANT SELECT,UPDATE on timezones_our_tzno_seq to davical_app
>> GRANT SELECT,INSERT on time_zone to davical_app
>> DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
>> /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
>> GRANT SELECT on supported_locales to davical_app
>> GRANT SELECT on awl_db_revision to davical_app
>> GRANT SELECT on principal_type to davical_app
>> Database permissions updated.
>>
>> Is there a possibility to repair this without a lot of work?
>> I think that the DAViCal is running well!?
>>
>> Kind regards
>> Ingo Belka
>> ----
>> Stadt Grimmen, Markt 1, 18507 Grimmen
>> Grimmen - merk würdig schön http://www.grimmen.de
>> Tel.: +49 38326 47 228 ingo_belka@grimmen.de
>> Fax : +49 38326 47 255 hauptverwaltung@grimmen.de
>>
>> Am 27.09.2011 09:31, schrieb Vincent Van Houtte:
>>> Hi,
>>>
>>>> I got an error while upgrading DAViCal to 0.9.9.6-1.
>>> [...]
>>>> DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
>>>> /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
>>>> Database permissions updated.
>>>>
>>>> What went wrong? What do have to do in this situation?
>>>
>>> Did you follow this procedure?
>>> http://wiki.davical.org/w/Update-davical-database
>>>
>>> HTH,
>>>
>>> Vincent
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Davical-general mailing list
>> Davical-general@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/davical-general
>

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

I am NOT code savvy and am having the same problem.

I did a search for "time_zone", "time_" and finally "time" in the database update file on our server and none were found. Should there have been a new update DB in the apt-get update?


On 09/27/2011 08:44 AM, Ingo Belka wrote:

Hello again, I put the value in /etc/php5/apache2/php.ini. Then I restarted the system, but no success. The error left. Are there any other suggestions/solutions? Kind regards Ingo Belka ---- Stadt Grimmen, Markt 1, 18507 Grimmen Grimmen - merk würdig schön http://www.grimmen.de"]http://www.grimmen.de Tel.: +49 38326 47 228 ingo_belka@grimmen.de Fax : +49 38326 47 255 hauptverwaltung@grimmen.de Am 27.09.2011 16:27, schrieb Wolfgang Hennerbichler:

Hi Ingo, your problem is your php.ini, has nothing to do with davical but php. put this into your php.ini: date.timezone = Europe/Berlin and all is good. wolfgang On Tue, Sep 27, 2011 at 03:59:35PM +0200, Ingo Belka wrote:

Hi Vincent, I did read the wiki. But there is no help for this problem and I hope I can avoid the roll back of code. The German error message says that the relation "time_zone" does not exist. But it seem to me that everything is fine except this one thing with the time_zone. I started the database update with -debug option and this is the output: davical@ubuntu:~$ sudo /usr/share/davical/dba/update-davical-database -debug [sudo] password for davical: Using database: davical_dba%@dbi:Pg:dbname=davical The database is version 8.4 currently at revision 1.2.11. Looking at patches[0] (1.1.2.sql) Patch 1.1.2.sql has already been applied. Looking at patches[1] (1.1.3.sql) Patch 1.1.3.sql has already been applied. Looking at patches[2] (1.1.4.sql) Patch 1.1.4.sql has already been applied. Looking at patches[3] (1.1.5.sql) Patch 1.1.5.sql has already been applied. Looking at patches[4] (1.1.6.sql) Patch 1.1.6.sql has already been applied. Looking at patches[5] (1.1.7.sql) Patch 1.1.7.sql has already been applied. Looking at patches[6] (1.1.8.sql) Patch 1.1.8.sql has already been applied. Looking at patches[7] (1.1.9.sql) Patch 1.1.9.sql has already been applied. Looking at patches[8] (1.1.10.sql) Patch 1.1.10.sql has already been applied. Looking at patches[9] (1.1.11.sql) Patch 1.1.11.sql has already been applied. Looking at patches[10] (1.1.11a.sql) Patch 1.1.11a.sql has already been applied. Looking at patches[11] (1.1.12.sql) Patch 1.1.12.sql has already been applied. Looking at patches[12] (1.1.12a.sql) Patch 1.1.12a.sql has already been applied. Looking at patches[13] (1.2.1.sql) Patch 1.2.1.sql has already been applied. Looking at patches[14] (1.2.1a.sql) Patch 1.2.1a.sql has already been applied. Looking at patches[15] (1.2.1b.sql) Patch 1.2.1b.sql has already been applied. Looking at patches[16] (1.2.2.sql) Patch 1.2.2.sql has already been applied. Looking at patches[17] (1.2.3.sql) Patch 1.2.3.sql has already been applied. Looking at patches[18] (1.2.3a.sql) Patch 1.2.3a.sql has already been applied. Looking at patches[19] (1.2.4.sql) Patch 1.2.4.sql has already been applied. Looking at patches[20] (1.2.5.sql) Patch 1.2.5.sql has already been applied. Looking at patches[21] (1.2.6.sql) Patch 1.2.6.sql has already been applied. Looking at patches[22] (1.2.7.sql) Patch 1.2.7.sql has already been applied. Looking at patches[23] (1.2.8.sql) Patch 1.2.8.sql has already been applied. Looking at patches[24] (1.2.9.sql) Patch 1.2.9.sql has already been applied. Looking at patches[25] (1.2.10.sql) Patch 1.2.10.sql has already been applied. Looking at patches[26] (1.2.10a.sql) Patch 1.2.10a.sql has already been applied. Looking at patches[27] (1.2.11.sql) Patch 1.2.11.sql has already been applied. No patches were applied. Supported locales updated. Updated view: dav_principal.sql applied. CalDAV functions updated. RRULE functions updated. GRANT SELECT,INSERT,UPDATE,DELETE on collection to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on caldav_data to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on calendar_item to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on relationship to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on locks to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on property to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on freebusy_ticket to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on usr to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on usr_setting to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on roles to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on role_member to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on session to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on tmp_password to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on group_member to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on principal to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on relationship_type to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on sync_tokens to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on sync_changes to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on grants to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on dav_principal to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on access_ticket to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on dav_binding to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on calendar_alarm to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on calendar_attendee to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_resource to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_adr to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_tel to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_email to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on timezones to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on tz_aliases to davical_app GRANT SELECT,INSERT,UPDATE,DELETE on tz_localnames to davical_app GRANT SELECT,UPDATE on relationship_type_rt_id_seq to davical_app GRANT SELECT,UPDATE on dav_id_seq to davical_app GRANT SELECT,UPDATE on usr_user_no_seq to davical_app GRANT SELECT,UPDATE on roles_role_no_seq to davical_app GRANT SELECT,UPDATE on session_session_id_seq to davical_app GRANT SELECT,UPDATE on principal_type_principal_type_id_seq to davical_app GRANT SELECT,UPDATE on sync_tokens_sync_token_seq to davical_app GRANT SELECT,UPDATE on timezones_our_tzno_seq to davical_app GRANT SELECT,INSERT on time_zone to davical_app DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63. GRANT SELECT on supported_locales to davical_app GRANT SELECT on awl_db_revision to davical_app GRANT SELECT on principal_type to davical_app Database permissions updated. Is there a possibility to repair this without a lot of work? I think that the DAViCal is running well!? Kind regards Ingo Belka ---- Stadt Grimmen, Markt 1, 18507 Grimmen Grimmen - merk würdig schön http://www.grimmen.de"]http://www.grimmen.de Tel.: +49 38326 47 228 ingo_belka@grimmen.de Fax : +49 38326 47 255 hauptverwaltung@grimmen.de Am 27.09.2011 09:31, schrieb Vincent Van Houtte:

Hi,

I got an error while upgrading DAViCal to 0.9.9.6-1.

[..]

DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63. Database permissions updated. What went wrong? What do have to do in this situation?

Did you follow this procedure? http://wiki.davical.org/w/Update-davical-database"]http://wiki.davical.org/w/Update-davical-database HTH, Vincent

------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1"]http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Davical-general mailing list Davical-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/davical-general"]https://lists.sourceforge.net/lists/listinfo/davical-general

------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1"]http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Davical-general mailing list Davical-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/davical-general"]https://lists.sourceforge.net/lists/listinfo/davical-general

On 27.09.2011 17:44 Ingo Belka wrote:

> Hello again,
>
> I put the value in /etc/php5/apache2/php.ini. Then I restarted the
> system, but no success. The error left.

Same here:
# grep timezone /etc/php5/apache2/php.ini
date.timezone = Europe/Berlin

# /usr/share/davical/dba/update-davical-database --dbuser=davical_dba
The database is version 8.4 currently at revision 1.2.11.
No patches were applied.
Supported locales updated.
Updated view: dav_principal.sql applied.
CalDAV functions updated.
RRULE functions updated.
DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
/usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
Database permissions updated.

> Are there any other suggestions/solutions?

Could this be the reason (last line)?:

root@u1004a:/usr/share/davical/dba# grep time_zone * */*
appuser_permissions.txt: ON time_zone
patches/1.2.11.sql:-- Minor enhancement: Add columns to time_zone
table to support timezone protocol changes.
patches/1.2.11.sql: SELECT tz_id, tz_locn, false,
'1970-01-01T00:00:00Z', tz_spec, 'import' FROM time_zone;
patches/1.2.11.sql: SELECT timezones.our_tzno, tz_locn FROM time_zone
LEFT JOIN timezones ON (tz_id = tzid)
patches/1.2.11.sql:DROP TABLE time_zone CASCADE;


-Michael

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

I have the same problem after the update. Furthermore, the
administration interface lists the following issue under
Administration->Setup:

Dependency Status
---------- ------
Current DAViCal version Want: 0.9.9.5, Currently: 0.9.9.6

Is this a problem? (Clients seem to access the davical server fine for now.)


Mihai


On 09/27/2011 11:44 AM, Ingo Belka wrote:
> Hello again,
>
> I put the value in /etc/php5/apache2/php.ini. Then I restarted the
> system, but no success. The error left.
>
> Are there any other suggestions/solutions?
>
> Kind regards
> Ingo Belka
> ----
> Stadt Grimmen, Markt 1, 18507 Grimmen
> Grimmen - merk würdig schön http://www.grimmen.de
> Tel.: +49 38326 47 228 ingo_belka@grimmen.de
> Fax : +49 38326 47 255 hauptverwaltung@grimmen.de
>
> Am 27.09.2011 16:27, schrieb Wolfgang Hennerbichler:
>> Hi Ingo,
>>
>> your problem is your php.ini, has nothing to do with davical but php.
>>
>> put this into your php.ini:
>> date.timezone = Europe/Berlin
>>
>> and all is good.
>> wolfgang
>>
>> On Tue, Sep 27, 2011 at 03:59:35PM +0200, Ingo Belka wrote:
>>> Hi Vincent,
>>>
>>> I did read the wiki. But there is no help for this problem and I hope I
>>> can avoid the roll back of code. The German error message says that the
>>> relation "time_zone" does not exist.
>>>
>>> But it seem to me that everything is fine except this one thing with the
>>> time_zone.
>>>
>>> I started the database update with -debug option and this is the output:
>>> davical@ubuntu:~$ sudo /usr/share/davical/dba/update-davical-database -debug
>>> [sudo] password for davical:
>>> Using database: davical_dba%@dbi:Pg:dbname=davical
>>> The database is version 8.4 currently at revision 1.2.11.
>>> Looking at patches[0] (1.1.2.sql)
>>> Patch 1.1.2.sql has already been applied.
>>> Looking at patches[1] (1.1.3.sql)
>>> Patch 1.1.3.sql has already been applied.
>>> Looking at patches[2] (1.1.4.sql)
>>> Patch 1.1.4.sql has already been applied.
>>> Looking at patches[3] (1.1.5.sql)
>>> Patch 1.1.5.sql has already been applied.
>>> Looking at patches[4] (1.1.6.sql)
>>> Patch 1.1.6.sql has already been applied.
>>> Looking at patches[5] (1.1.7.sql)
>>> Patch 1.1.7.sql has already been applied.
>>> Looking at patches[6] (1.1.8.sql)
>>> Patch 1.1.8.sql has already been applied.
>>> Looking at patches[7] (1.1.9.sql)
>>> Patch 1.1.9.sql has already been applied.
>>> Looking at patches[8] (1.1.10.sql)
>>> Patch 1.1.10.sql has already been applied.
>>> Looking at patches[9] (1.1.11.sql)
>>> Patch 1.1.11.sql has already been applied.
>>> Looking at patches[10] (1.1.11a.sql)
>>> Patch 1.1.11a.sql has already been applied.
>>> Looking at patches[11] (1.1.12.sql)
>>> Patch 1.1.12.sql has already been applied.
>>> Looking at patches[12] (1.1.12a.sql)
>>> Patch 1.1.12a.sql has already been applied.
>>> Looking at patches[13] (1.2.1.sql)
>>> Patch 1.2.1.sql has already been applied.
>>> Looking at patches[14] (1.2.1a.sql)
>>> Patch 1.2.1a.sql has already been applied.
>>> Looking at patches[15] (1.2.1b.sql)
>>> Patch 1.2.1b.sql has already been applied.
>>> Looking at patches[16] (1.2.2.sql)
>>> Patch 1.2.2.sql has already been applied.
>>> Looking at patches[17] (1.2.3.sql)
>>> Patch 1.2.3.sql has already been applied.
>>> Looking at patches[18] (1.2.3a.sql)
>>> Patch 1.2.3a.sql has already been applied.
>>> Looking at patches[19] (1.2.4.sql)
>>> Patch 1.2.4.sql has already been applied.
>>> Looking at patches[20] (1.2.5.sql)
>>> Patch 1.2.5.sql has already been applied.
>>> Looking at patches[21] (1.2.6.sql)
>>> Patch 1.2.6.sql has already been applied.
>>> Looking at patches[22] (1.2.7.sql)
>>> Patch 1.2.7.sql has already been applied.
>>> Looking at patches[23] (1.2.8.sql)
>>> Patch 1.2.8.sql has already been applied.
>>> Looking at patches[24] (1.2.9.sql)
>>> Patch 1.2.9.sql has already been applied.
>>> Looking at patches[25] (1.2.10.sql)
>>> Patch 1.2.10.sql has already been applied.
>>> Looking at patches[26] (1.2.10a.sql)
>>> Patch 1.2.10a.sql has already been applied.
>>> Looking at patches[27] (1.2.11.sql)
>>> Patch 1.2.11.sql has already been applied.
>>> No patches were applied.
>>> Supported locales updated.
>>> Updated view: dav_principal.sql applied.
>>> CalDAV functions updated.
>>> RRULE functions updated.
>>> GRANT SELECT,INSERT,UPDATE,DELETE on collection to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on caldav_data to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on calendar_item to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on relationship to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on locks to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on property to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on freebusy_ticket to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on usr to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on usr_setting to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on roles to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on role_member to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on session to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on tmp_password to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on group_member to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on principal to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on relationship_type to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on sync_tokens to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on sync_changes to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on grants to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on dav_principal to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on access_ticket to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on dav_binding to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on calendar_alarm to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on calendar_attendee to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_resource to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_adr to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_tel to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on addressbook_address_email to
>>> davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on timezones to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on tz_aliases to davical_app
>>> GRANT SELECT,INSERT,UPDATE,DELETE on tz_localnames to davical_app
>>> GRANT SELECT,UPDATE on relationship_type_rt_id_seq to davical_app
>>> GRANT SELECT,UPDATE on dav_id_seq to davical_app
>>> GRANT SELECT,UPDATE on usr_user_no_seq to davical_app
>>> GRANT SELECT,UPDATE on roles_role_no_seq to davical_app
>>> GRANT SELECT,UPDATE on session_session_id_seq to davical_app
>>> GRANT SELECT,UPDATE on principal_type_principal_type_id_seq to davical_app
>>> GRANT SELECT,UPDATE on sync_tokens_sync_token_seq to davical_app
>>> GRANT SELECT,UPDATE on timezones_our_tzno_seq to davical_app
>>> GRANT SELECT,INSERT on time_zone to davical_app
>>> DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
>>> /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
>>> GRANT SELECT on supported_locales to davical_app
>>> GRANT SELECT on awl_db_revision to davical_app
>>> GRANT SELECT on principal_type to davical_app
>>> Database permissions updated.
>>>
>>> Is there a possibility to repair this without a lot of work?
>>> I think that the DAViCal is running well!?
>>>
>>> Kind regards
>>> Ingo Belka
>>> ----
>>> Stadt Grimmen, Markt 1, 18507 Grimmen
>>> Grimmen - merk würdig schön http://www.grimmen.de
>>> Tel.: +49 38326 47 228 ingo_belka@grimmen.de
>>> Fax : +49 38326 47 255 hauptverwaltung@grimmen.de
>>>
>>> Am 27.09.2011 09:31, schrieb Vincent Van Houtte:
>>>> Hi,
>>>>
>>>>> I got an error while upgrading DAViCal to 0.9.9.6-1.
>>>> [...]
>>>>> DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
>>>>> /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
>>>>> Database permissions updated.
>>>>>
>>>>> What went wrong? What do have to do in this situation?
>>>>
>>>> Did you follow this procedure?
>>>> http://wiki.davical.org/w/Update-davical-database
>>>>
>>>> HTH,
>>>>
>>>> Vincent
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>> _______________________________________________
>>> Davical-general mailing list
>>> Davical-general@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/davical-general
>>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Davical-general mailing list
> Davical-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/davical-general

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

On Tue, 27 Sep 2011 18:56:33 +0200
Michael Lackhoff <michael@lackhoff.de> wrote:


> DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
> /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
> Database permissions updated.
>
If you do: \d time_zone what do you get?

davical=# \d time_zone
Table "public.time_zone"
Column | Type | Modifiers
---------+------+-----------
tz_id | text | not null
tz_locn | text |
tz_spec | text |
Indexes:
"time_zone_pkey" PRIMARY KEY, btree (tz_id)
Referenced by:
TABLE "calendar_item" CONSTRAINT "calendar_item_tz_id_fkey" FOREIGN
KEY (tz_id) REFERENCES time_zone(tz_id) TABLE "collection" CONSTRAINT
"collection_timezone_fkey" FOREIGN KEY (timezone) REFERENCES
time_zone(tz_id) ON UPDATE CASCADE ON DELETE SET NULL


--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

On Tue, 27 Sep 2011 18:56:33 +0200
Michael Lackhoff <michael@lackhoff.de> wrote:

> On 27.09.2011 17:44 Ingo Belka wrote:
>
> > Hello again,
> >
> > I put the value in /etc/php5/apache2/php.ini. Then I restarted the
> > system, but no success. The error left.
>
> Same here:
> # grep timezone /etc/php5/apache2/php.ini
> date.timezone = Europe/Berlin
>
> # /usr/share/davical/dba/update-davical-database --dbuser=davical_dba
> The database is version 8.4 currently at revision 1.2.11.
> No patches were applied.
> Supported locales updated.
> Updated view: dav_principal.sql applied.
> CalDAV functions updated.
> RRULE functions updated.
> DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
> /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.
> Database permissions updated.
>
> > Are there any other suggestions/solutions?
>
> Could this be the reason (last line)?:
>
> root@u1004a:/usr/share/davical/dba# grep time_zone * */*
> appuser_permissions.txt: ON time_zone
> patches/1.2.11.sql:-- Minor enhancement: Add columns to time_zone
> table to support timezone protocol changes.
> patches/1.2.11.sql: SELECT tz_id, tz_locn, false,
> '1970-01-01T00:00:00Z', tz_spec, 'import' FROM time_zone;
> patches/1.2.11.sql: SELECT timezones.our_tzno, tz_locn FROM time_zone
> LEFT JOIN timezones ON (tz_id = tzid)
> patches/1.2.11.sql:DROP TABLE time_zone CASCADE;
>
/usr/share/davical/dba/davical.sql
-- Not particularly needed, perhaps, except as a way to collect
-- a bunch of valid iCalendar time zone specifications... :-)
CREATE TABLE time_zone (
tz_id TEXT PRIMARY KEY,
tz_locn TEXT,
tz_spec TEXT
);


-- Something that can look like a filesystem hierarchy where we store
stuff CREATE TABLE collection (
user_no INT references usr(user_no) ON UPDATE CASCADE ON DELETE
CASCADE DEFERRABLE, parent_container TEXT,
dav_name TEXT,
dav_etag TEXT,
dav_displayname TEXT,
is_calendar BOOLEAN,
created TIMESTAMP WITH TIME ZONE,
modified TIMESTAMP WITH TIME ZONE,
public_events_only BOOLEAN NOT NULL DEFAULT FALSE,
publicly_readable BOOLEAN NOT NULL DEFAULT FALSE,
collection_id INT8 PRIMARY KEY DEFAULT nextval('dav_id_seq'),
default_privileges BIT(24),
is_addressbook BOOLEAN DEFAULT FALSE,
resourcetypes TEXT DEFAULT '<DAV::collection/>',
schedule_transp TEXT DEFAULT 'opaque',
timezone TEXT REFERENCES time_zone(tz_id) ON DELETE SET NULL ON
UPDATE CASCADE, description TEXT DEFAULT '',
UNIQUE(user_no,dav_name)
);

The above is the initial davical database and to that a number of
patches has been applied (1.2.3a.sql, 1.2.3.sql, 1.2.7.sql):
grep -Hn time_zone patches/*
patches/1.2.3a.sql:38:ALTER TABLE calendar_item ADD CONSTRAINT
"calendar_item_tz_id_fkey" FOREIGN KEY (tz_id) REFERENCES
time_zone(tz_id) ON UPDATE CASCADE ON DELETE CASCADE DEFERRABLE;
patches/1.2.3.sql:57:ALTER TABLE calendar_item ADD CONSTRAINT
"calendar_item_tz_id_fkey" FOREIGN KEY (tz_id) REFERENCES
time_zone(tz_id) ON UPDATE CASCADE ON DELETE CASCADE DEFERRABLE;
patches/1.2.7.sql:28:ALTER TABLE collection ADD COLUMN timezone TEXT
REFERENCES time_zone(tz_id) ON DELETE SET NULL ON UPDATE CASCADE;

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

On 27.09.2011 19:41 Michael Rasmussen wrote:

> If you do: \d time_zone what do you get?
>
> davical=# \d time_zone
> Table "public.time_zone"
> Column | Type | Modifiers
> ---------+------+-----------
> tz_id | text | not null
> tz_locn | text |
> tz_spec | text |
> Indexes:
> "time_zone_pkey" PRIMARY KEY, btree (tz_id)
> Referenced by:
> TABLE "calendar_item" CONSTRAINT "calendar_item_tz_id_fkey" FOREIGN
> KEY (tz_id) REFERENCES time_zone(tz_id) TABLE "collection" CONSTRAINT
> "collection_timezone_fkey" FOREIGN KEY (timezone) REFERENCES
> time_zone(tz_id) ON UPDATE CASCADE ON DELETE SET NULL

As expected I get:
postgres@u1004a:~$ psql
psql (8.4.8)
Geben Sie »help« für Hilfe ein.

postgres=# \d time_zone
Keine Relationen namens »time_zone« gefunden
postgres=#

(I am not really fluent in postgres, is it ok to do it this way or do I
have to select the database first?)

And what about this command in 1.2.11.sql?:
DROP TABLE time_zone CASCADE;

-Michael

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

On Tue, 27 Sep 2011 08:43:51 +0200
Ingo Belka <ingo_belka@grimmen.de> wrote:

>
> What went wrong? What do have to do in this situation?
>
I had a sane 0.9.9.5 installation working and upgrading to 0.9.9.6
utterly failed. The reason seems to be related to the check for current
database version done in patch 1.2.11.sql since the update script fails:
Applying patch 1.2.11.sql ... failed!
psql:./patches/1.2.11.sql:5: ERROR: Database has not been upgraded to
1.2.10

Thereby leaving the database in and unstable state.

What apparently goes wrong is that the database for some reason thinks
it is at version 1.2.9. (Below done after af pg_restore from a pg_dump
done just before upgrading to 0.9.9.6)

SELECT check_db_revision(1,2,10);
ERROR: Database has not been upgraded to 1.2.10
--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

On Tue, 27 Sep 2011 08:43:51 +0200
Ingo Belka <ingo_belka@grimmen.de> wrote:

>
> What went wrong? What do have to do in this situation?
>
Applying 1.2.10 manually:
psql davical davical_dba < patches/1.2.10.sql
ALTER TABLE
ALTER TABLE
CREATE FUNCTION
BEGIN
ERROR: Database revisions after 1.2.9 have already been applied.
ERROR: current transaction is aborted, commands ignored until end of
transaction block ERROR: current transaction is aborted, commands
ignored until end of transaction block ERROR: current transaction is
aborted, commands ignored until end of transaction block ERROR:
current transaction is aborted, commands ignored until end of
transaction block ERROR: current transaction is aborted, commands
ignored until end of transaction block ERROR: current transaction is
aborted, commands ignored until end of transaction block ERROR:
current transaction is aborted, commands ignored until end of
transaction block ERROR: current transaction is aborted, commands
ignored until end of transaction block ERROR: current transaction is
aborted, commands ignored until end of transaction block ERROR:
current transaction is aborted, commands ignored until end of
transaction block ERROR: current transaction is aborted, commands
ignored until end of transaction block ROLLBACK NOTICE: there is no
transaction in progress ROLLBACK


--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

On 27.09.2011 19:48 Michael Rasmussen wrote:

> /usr/share/davical/dba/davical.sql
> -- Not particularly needed, perhaps, except as a way to collect
> -- a bunch of valid iCalendar time zone specifications... :-)
> CREATE TABLE time_zone (
> tz_id TEXT PRIMARY KEY,
> tz_locn TEXT,
> tz_spec TEXT
> );

This is not in mine:
root@u1004a:/usr/share/davical/dba# ll davical.sql
-rw-r--r-- 1 root root 14892 2011-09-24 02:13 davical.sql

It looks recent and has no time_zone table. What is your version and
where did you get it? (I got mine via apt-get upgrade)

-Michael

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

On Tue, 27 Sep 2011 23:40:17 +0200
Michael Lackhoff <michael@lackhoff.de> wrote:

>
> This is not in mine:
> root@u1004a:/usr/share/davical/dba# ll davical.sql
> -rw-r--r-- 1 root root 14892 2011-09-24 02:13 davical.sql
>
> It looks recent and has no time_zone table. What is your version and
> where did you get it? (I got mine via apt-get upgrade)
>
I have solved the case:-) The solution below ONLY applies to a
davical-0.9.9.5 database for which you have not run
update-davical-database from davical-0.9.9.6. It is strongly
recommended to run: pg_dump -Fc <your davical database name> >
davical-0.9.9.5.dump before doing anything below.

1) 0.9.9.6 has a patch called 1.2.10a.sql which is never applied. The
patch though, contains errors which must be commented out before a
clean apply can be done. See my attached 1.2.10b.sql
psql <your davical database name> davical_dba < 1.2.10b.sql

2) The file appuser_permissions.txt has a reference to time_zone which
must be commented out. See my attached appuser_permissions_a.txt

3) Now run update-davical-database

Even after running update-davical-database the web interface still
shows: Current DAViCal version Want: 0.9.9.5, Currently: 0.9.9.6
for which I have no solution.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

Hi Michael R.,

thank you for your efforts.

Your solutions works fine for me. The only thing left is the false
DAViCal-Version in the web gui. May be Andrew can give us a workaround
to solve that.

DAViCal itself seem to work normal - that's the main thing.


Kind regards
Ingo Belka
----
Stadt Grimmen, Markt 1, 18507 Grimmen
Grimmen - merk würdig schön http://www.grimmen.de
Tel.: +49 38326 47 228 ingo_belka@grimmen.de
Fax : +49 38326 47 255 hauptverwaltung@grimmen.de

Am 28.09.2011 00:22, schrieb Michael Rasmussen:
> On Tue, 27 Sep 2011 23:40:17 +0200 Michael Lackhoff
> <michael@lackhoff.de> wrote:
>
>>
>> This is not in mine: root@u1004a:/usr/share/davical/dba# ll
>> davical.sql -rw-r--r-- 1 root root 14892 2011-09-24 02:13
>> davical.sql
>>
>> It looks recent and has no time_zone table. What is your version
>> and where did you get it? (I got mine via apt-get upgrade)
>>
> I have solved the case:-) The solution below ONLY applies to a
> davical-0.9.9.5 database for which you have not run
> update-davical-database from davical-0.9.9.6. It is strongly
> recommended to run: pg_dump -Fc <your davical database name> >
> davical-0.9.9.5.dump before doing anything below.
>
> 1) 0.9.9.6 has a patch called 1.2.10a.sql which is never applied.
> The patch though, contains errors which must be commented out
> before a clean apply can be done. See my attached 1.2.10b.sql psql
> <your davical database name> davical_dba < 1.2.10b.sql
>
> 2) The file appuser_permissions.txt has a reference to time_zone
> which must be commented out. See my attached
> appuser_permissions_a.txt
>
> 3) Now run update-davical-database
>
> Even after running update-davical-database the web interface still
> shows: Current DAViCal version Want: 0.9.9.5, Currently: 0.9.9.6
> for which I have no solution.
>
>
>
>
> ------------------------------------------------------------------------------
>
>
All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and
> makes sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
>
>
>
> _______________________________________________ Davical-general
> mailing list Davical-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/davical-general

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Michael,

sorry I was to fast. I did overseen these error messages while
applying the 1.2.10b.sql, because someone disturbed me:

postgres@ubuntu:~$ psql davical davical_dba <
/home/davical/Downloads/1.2.10b.sql
CREATE FUNCTION
ALTER TABLE
ALTER TABLE
CREATE FUNCTION
BEGIN
FEHLER: Database revisions after 1.2.10 have already been applied.
FEHLER: aktuelle Transaktion wurde abgebrochen, Befehle werden bis
zum Ende der Transaktion ignoriert
FEHLER: aktuelle Transaktion wurde abgebrochen, Befehle werden bis
zum Ende der Transaktion ignoriert
FEHLER: aktuelle Transaktion wurde abgebrochen, Befehle werden bis
zum Ende der Transaktion ignoriert
FEHLER: aktuelle Transaktion wurde abgebrochen, Befehle werden bis
zum Ende der Transaktion ignoriert
FEHLER: aktuelle Transaktion wurde abgebrochen, Befehle werden bis
zum Ende der Transaktion ignoriert
FEHLER: aktuelle Transaktion wurde abgebrochen, Befehle werden bis
zum Ende der Transaktion ignoriert
ROLLBACK
HINWEIS: keine Transaktion offen
ROLLBACK

After all there is no relation "time_zone" in the database.

Kind regards
Ingo Belka
- ----
Stadt Grimmen, Markt 1, 18507 Grimmen
Grimmen - merk würdig schön http://www.grimmen.de
Tel.: +49 38326 47 228 ingo_belka@grimmen.de
Fax : +49 38326 47 255 hauptverwaltung@grimmen.de

Am 28.09.2011 00:22, schrieb Michael Rasmussen:
> On Tue, 27 Sep 2011 23:40:17 +0200 Michael Lackhoff
> <michael@lackhoff.de> wrote:
>
>>
>> This is not in mine: root@u1004a:/usr/share/davical/dba# ll
>> davical.sql -rw-r--r-- 1 root root 14892 2011-09-24 02:13
>> davical.sql
>>
>> It looks recent and has no time_zone table. What is your version
>> and where did you get it? (I got mine via apt-get upgrade)
>>
> I have solved the case:-) The solution below ONLY applies to a
> davical-0.9.9.5 database for which you have not run
> update-davical-database from davical-0.9.9.6. It is strongly
> recommended to run: pg_dump -Fc <your davical database name> >
> davical-0.9.9.5.dump before doing anything below.
>
> 1) 0.9.9.6 has a patch called 1.2.10a.sql which is never applied.
> The patch though, contains errors which must be commented out
> before a clean apply can be done. See my attached 1.2.10b.sql psql
> <your davical database name> davical_dba < 1.2.10b.sql
>
> 2) The file appuser_permissions.txt has a reference to time_zone
> which must be commented out. See my attached
> appuser_permissions_a.txt
>
> 3) Now run update-davical-database
>
> Even after running update-davical-database the web interface still
> shows: Current DAViCal version Want: 0.9.9.5, Currently: 0.9.9.6
> for which I have no solution.
>
>
>
>
> ------------------------------------------------------------------------------
>
>
All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and
> makes sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
>
>
>
> _______________________________________________ Davical-general
> mailing list Davical-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/davical-general
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOgrQbAAoJEAzinZepZXEaz1wH/3W693Sdduw376k+X/LN8e9/
2E7kWd9J2wr4aSN0P9ksatX4+U53LFJIvAdsK/xFDETmkcIEYqiGvgbsdHqQjTqN
64fTgs121MYDEbdEOFmhJaNbXhYQ8YyGfND6+BTgKhsalN0FIVjm/uUUxrv+GY6U
mR0ybSdlrd39jMT6vjL5JSQBoniNAltcAGILz46YrutVLzYTLgZ8k/e9gTa1pog8
pHq6d4KmJrOx7JSZGGTP6ky/c9dfYbm7vKeSMUuteiWVwzq/+XDqziI9juAlPVZX
ZcWFCz+BP+o1i5j5PsUjKwYTvm9IbQColmvZo2oRe85kUk7fMcQ+G2wWUCfAYAo=
=RI0X
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

On 28.09.2011 00:22 Michael Rasmussen wrote:

> I have solved the case:-) The solution below ONLY applies to a
> davical-0.9.9.5 database for which you have not run
> update-davical-database from davical-0.9.9.6. It is strongly

But what can I do if I have already run the update script (as I have)?
If all that is missing is the time_zone table (or timezone data in
another table) that should be recreatable from some standard data but
since I am not really understanding yet what is going on I am a bit
reluctant trying too much and thus making things worse.

> recommended to run: pg_dump -Fc <your davical database name> >
> davical-0.9.9.5.dump before doing anything below.

I do not think I still have a 0.9.9.5 database to backup (I know I
should have).

Any ideas how to save/repair the mess?

-Michael

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 28 Sep 2011 07:43:55 +0200
Ingo Belka <ingo_belka@grimmen.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Michael,
>
> sorry I was to fast. I did overseen these error messages while
> applying the 1.2.10b.sql, because someone disturbed me:
>
What out does the following query give?
select schema_major, schema_minor, schema_patch, schema_name from
awl_db_revision;

Before applying 1.2.10b you should see:
schema_major | schema_minor | schema_patch | schema_name
- --------------+--------------+--------------+-------------
1 | 1 | 0 | Dawn
1 | 2 | 7 | Juillet
1 | 2 | 8 | Août
1 | 2 | 9 | Septembre
1 | 2 | 10 | Octobre

After applying 1.2.10b you should see:
schema_major | schema_minor | schema_patch | schema_name
- --------------+--------------+--------------+-------------
1 | 1 | 0 | Dawn
1 | 2 | 7 | Juillet
1 | 2 | 8 | Août
1 | 2 | 9 | Septembre
1 | 2 | 10 | Octobre
1 | 2 | 10 | Octobre

But none the less the following set of commands should solve your issue:
(use attached patch instead)

ALTER TABLE dav_binding ADD UNIQUE( dav_name );

ALTER TABLE principal ADD CONSTRAINT unique_user UNIQUE (user_no);

- -- Ensure we don't refer to any newer, duplicated collections
UPDATE caldav_data SET collection_id = (SELECT min(c2.collection_id)
FROM collection c1, collection c2 WHERE c1.dav_name = c2.dav_name AND
c1.collection_id = caldav_data.collection_id) WHERE collection_id >
(SELECT min(c2.collection_id) FROM collection c1, collection c2 WHERE
c1.dav_name = c2.dav_name AND c1.collection_id =
caldav_data.collection_id); -- Ensure the newer duplicated collections
don't exist any longer DELETE FROM collection WHERE collection_id >
(SELECT min(collection_id) FROM collection c2 WHERE c2.dav_name =
collection.dav_name); -- Ensure we can't add more duplicates in the
future ALTER TABLE collection ADD CONSTRAINT unique_path UNIQUE
(dav_name);

SELECT new_db_revision(1,2,10, 'Octobre' );

- --
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
- --------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6DR+4ACgkQQQOPluUB9RyplwCgy5YAuBWYAG08z1pbHH+WHq/K
3lkAoLsUyksMLRCydB99aJeqHThTNnzg
=Ii+S
-----END PGP SIGNATURE-----

May I chime in, I have the same issue. I believe I upgraded from 0.9.9.4
but I am not sure anymore.

No, I have not made a backup of the database.
No, I did not save the messages that ran through when applying the
update script, but I remember everything went through except for this
error.

Davical does work fine though. Can anyone confirm that this is a minor
issue that will be fixed or do I have to export all my data and do a
clean install?

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

I'm holding my breath and hoping:
1) I don't loose any data with the horked-up database issue.
2) someone can write a patch for us semi-illiterate users to get back on our feet.

Thanks for the hard work, it truly is appreciated!
Jon Archer
"I can't change the direction of the wind, but I can adjust my sails to always reach my destination." - Jimmy Dean

---

Down to Earth Enterprises - Psychological Services
1237 W. Auburn Dr.
Tempe, AZ 85283
http://www.drmarlo.com"]www.drmarlo.com
480-705-5007

---

http://www.genbook.com/bookings/slot/reservation/30106295?bookingSourceId=1000"]
On 09/28/2011 09:14 AM, Michael Rasmussen wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 28 Sep 2011 07:43:55 +0200 Ingo Belka <ingo_belka@grimmen.de> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, sorry I was to fast. I did overseen these error messages while applying the 1.2.10b.sql, because someone disturbed me:

What out does the following query give? select schema_major, schema_minor, schema_patch, schema_name from awl_db_revision; Before applying 1.2.10b you should see: schema_major | schema_minor | schema_patch | schema_name - --------------+--------------+--------------+------------- 1 | 1 | 0 | Dawn 1 | 2 | 7 | Juillet 1 | 2 | 8 | Ao&Atilde;&raquo;t 1 | 2 | 9 | Septembre 1 | 2 | 10 | Octobre After applying 1.2.10b you should see: schema_major | schema_minor | schema_patch | schema_name - --------------+--------------+--------------+------------- 1 | 1 | 0 | Dawn 1 | 2 | 7 | Juillet 1 | 2 | 8 | Ao&Atilde;&raquo;t 1 | 2 | 9 | Septembre 1 | 2 | 10 | Octobre 1 | 2 | 10 | Octobre But none the less the following set of commands should solve your issue: (use attached patch instead) ALTER TABLE dav_binding ADD UNIQUE( dav_name ); ALTER TABLE principal ADD CONSTRAINT unique_user UNIQUE (user_no); - -- Ensure we don't refer to any newer, duplicated collections UPDATE caldav_data SET collection_id = (SELECT min(c2.collection_id) FROM collection c1, collection c2 WHERE c1.dav_name = c2.dav_name AND c1.collection_id = caldav_data.collection_id) WHERE collection_id > (SELECT min(c2.collection_id) FROM collection c1, collection c2 WHERE c1.dav_name = c2.dav_name AND c1.collection_id = caldav_data.collection_id); -- Ensure the newer duplicated collections don't exist any longer DELETE FROM collection WHERE collection_id > (SELECT min(collection_id) FROM collection c2 WHERE c2.dav_name = collection.dav_name); -- Ensure we can't add more duplicates in the future ALTER TABLE collection ADD CONSTRAINT unique_path UNIQUE (dav_name); SELECT new_db_revision(1,2,10, 'Octobre' ); - -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael <at> rasmussen <dot> cc http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E"]http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E mir <at> datanom <dot> net http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C"]http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C mir <at> miras <dot> org http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917"]http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917 - -------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6DR+4ACgkQQQOPluUB9RyplwCgy5YAuBWYAG08z1pbHH+WHq/K 3lkAoLsUyksMLRCydB99aJeqHThTNnzg =Ii+S -----END PGP SIGNATURE-----

------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1"]http://p.sf.net/sfu/splunk-d2dcopy1

_______________________________________________ Davical-general mailing list Davical-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/davical-general"]https://lists.sourceforge.net/lists/listinfo/davical-general

On Tue, 27 Sep 2011 08:43:51 +0200
Ingo Belka <ingo_belka@grimmen.de> wrote:

> I got an error while upgrading DAViCal to 0.9.9.6-1.
>
In light of the current situation my a suggest applying the attached
patch to update-davical-database to avoid similar situations in the
future?

The script after patching, unless instructed otherwise, will
automatically create a backup of the present database before any
patching or database change has been made.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

On Tue, 2011-09-27 at 08:43 +0200, Ingo Belka wrote:
> Hello everybody,
>
> I got an error while upgrading DAViCal to 0.9.9.6-1.
>
> I'm using the sources ubuntu upgrading the system. As you can see from
> the list below, there was no problem installing the upgrade.

> .
> DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert nicht at
> /usr/share/davical/dba/update-davical-database line 400, <PERMS> line 63.


> What went wrong? What do have to do in this situation?

You can ignore this error. The table time_zone is not present in the
latest database version and the line mentioning it was left in the
permissions file by accident.

Cheers,
Andrew.
--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Accent on helpful side of your nature. Drain the moat.
------------------------------------------------------------------------

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Andrew,

thank you for your reply, that sounds very good. So I can left my
installation as it is in this moment, can't I?.

And this message seen in the web gui:

actual DAViCal-Version Want: 0.9.9.5, Currently: 0.9.9.6

will be solved with the next release!?

I love DAViCal because it's one of the best software running on my
systems. Thank you for your hard work on it.

Kind regards
Ingo Belka
- ----
Stadt Grimmen, Markt 1, 18507 Grimmen
Grimmen - merk würdig schön http://www.grimmen.de
Tel.: +49 38326 47 228 ingo_belka@grimmen.de
Fax : +49 38326 47 255 hauptverwaltung@grimmen.de

Am 29.09.2011 00:05, schrieb Andrew McMillan:
> On Tue, 2011-09-27 at 08:43 +0200, Ingo Belka wrote:
>> Hello everybody,
>>
>> I got an error while upgrading DAViCal to 0.9.9.6-1.
>>
>> I'm using the sources ubuntu upgrading the system. As you can
>> see from the list below, there was no problem installing the
>> upgrade.
>
>> . DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert
>> nicht at /usr/share/davical/dba/update-davical-database line
>> 400, <PERMS> line 63.
>
>
>> What went wrong? What do have to do in this situation?
>
> You can ignore this error. The table time_zone is not present in
> the latest database version and the line mentioning it was left in
> the permissions file by accident.
>
> Cheers, Andrew.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOg/2NAAoJEAzinZepZXEaAHYH/2PIXN1V9iuc6uVxB6CxePGv
txsC6N+p9m/qQbQrD2JcOvM+EY1iHK1hzOVUmCNcg/CneYn95NSCvxnOC6mbbRlV
VP3jyz/IvJML0zidX4P/Pf1dPNKA8gVJKseiH7sZEQvojpJteNqwKAs9sVXyaf7w
p76Lh9+it9gq+dpzSvx6FdWyanNqWI8hC2H9kDz/qoE59QgOTBXa/Yr5lZYxi+kZ
v1iKhi3b9CsRgg6J7qW73sTpn0CuxIoq5+hhmypO3ZB4EPP2qgo1i/M2vv8TBGS4
LqLUvQYqoWzVyKrBAhEpXikY2ZITP2aQ2pcUn63XE8infS+zcZA5Itijtag4RQE=
=EqLZ
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

Hi Andrew,

thank you for your reply, that sounds very good. So I can left my
installation as it is in this moment, can't I?.

And this message seen in the web gui:

actual DAViCal-Version Want: 0.9.9.5, Currently: 0.9.9.6

will be solved with the next release!?

I love DAViCal because it's one of the best software running on my
systems. Thank you for your hard work on it.

Kind regards
Ingo Belka
----
Stadt Grimmen, Markt 1, 18507 Grimmen
Grimmen - merk würdig schön http://www.grimmen.de
Tel.: +49 38326 47 228 ingo_belka@grimmen.de
Fax : +49 38326 47 255 hauptverwaltung@grimmen.de

Am 29.09.2011 00:05, schrieb Andrew McMillan:
> On Tue, 2011-09-27 at 08:43 +0200, Ingo Belka wrote:
>> Hello everybody,
>>
>> I got an error while upgrading DAViCal to 0.9.9.6-1.
>>
>> I'm using the sources ubuntu upgrading the system. As you can
>> see from the list below, there was no problem installing the
>> upgrade.
>
>> . DBD::Pg::db do failed: FEHLER: Relation »time_zone« existiert
>> nicht at /usr/share/davical/dba/update-davical-database line
>> 400, <PERMS> line 63.
>
>
>> What went wrong? What do have to do in this situation?
>
> You can ignore this error. The table time_zone is not present in
> the latest database version and the line mentioning it was left in
> the permissions file by accident.
>
> Cheers, Andrew.

------------------------------------------------------------------------------

All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general