Kolab 3.4: Disaster

Franz Skale i.bin at dah.am
Fri Mar 27 18:41:35 CET 2015



Hi,
i forgot to mention, that there's a bug report.
So you can try a mysql initialize, mentioned in the following kolab issue.
Scroll down near the end of the page.

Link:
https://issues.kolab.org/show_bug.cgi?id=4850


Rgds.

Franz

Am 26.03.15 um 20:22 schrieb Carpenter, Troy:
> On 2015-03-18 8:50 am, dsp3 wrote:
>> Stefan,
>> Try this:
>>
>> /⁠usr/⁠share/⁠roundcubemail/⁠bin/⁠updatedb.sh \
>>    -⁠-⁠dir /⁠usr/⁠share/⁠roundcubemail/⁠plugins/⁠libkolab/⁠SQL \
>>    -⁠-⁠package libkolab
>>
>> This was on Centos 6 system.
>>
>> SQL tables needed updating. My calendar items then re-⁠appeared.
>
> So I ran that command, and I'm getting an error related to the foreign
> key constraint for the kolab_cache_event table.  I've tried different
> ways to create the table with the proper constraint, but I cannot ever
> get mysql to accept "fk_kolab_cache_event_folder".  When I left that
> blank, it defaulted to "kolab_cache_event_ibfk_1", but I really don't
> understand those values and I would be willing to bet it's not
> correct.  How can I get the correct constraint back in the table?
>
> But this all begs another question, which is how can we tell if any
> tables for any of the other components were correctly upgraded?
>
> BTW - I found this website that might help with the table size:
>  
> http://webcache.googleusercontent.com/search?q=cache:7M7la3-8JC0J:vdachev.net/2007/02/22/mysql-reducing-ibdata1/
>
> Note that it requires dumping the database, and talks about setting
> limits on how big the tables can grow, but it can't fix the root issue
> about using InnoDB tables.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4254 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.kolab.org/pipermail/users/attachments/20150327/7997efec/attachment.p7s>


More information about the users mailing list