[5 ERR] Error adding addressbook from preset SOGo_autodiscovery: [1406] Data too long for column 'name' at row 1

[chaos-prevails]

Dear all,

I use SOGo as backend, and shared address books have the sharer with the full username (+domain) in their name, e.g.

name_of_addressbook ([email protected])

I see that the varchar limit for the name attribute in carddav_addressbook is 64 characters. However, my shared address book has 84 characters. This happens easily especially if the address book name is long (or the domain is long). I get the following error:

May 17 14:01:47 mail roundcube: <f093uvfo> [5 ERR] Error adding addressbook from preset SOGo_autodiscovery: [1406] Data too long for column 'name' at row 1 
May 17 14:01:47 mail roundcube: <f093uvfo> DB Error: [1406] Data too long for column 'name' at row 1 (SQL Query: INSERT INTO carddav_addressbooks(`name`,`username`,`password`,`url`,`user_id`,`sync_token`,`active`,`presetname`,`use_categories`,`refresh_time`) VALUES ('(addressbookname (addressbookname_XX.net-test (sharer-name <[email protected]>))','%u','{ENCRYPTED}XXXX','https://mail.mydomain.org/SOGo/dav/[email protected]/Contacts/314CF5-62837A80-B-XXYYZZWW/','5','','1','addressbookname','1','240')) in /opt/www/roundcubemail/program/lib/Roundcube/rcube_db.php on line 566 (POST /mail/?_task=login&_action=login)
May 17 14:01:47 mail roundcube: <f093uvfo> [5 ERR] Database::insert (INSERT INTO carddav_addressbooks(`name`,`username`,`password`,`url`,`user_id`,`sync_token`,`active`,`presetname`,`use_categories`,`refresh_time`) VALUES (?,?,?,?,?,?,?,?,?,?)) ERROR: [1406] Data too long for column 'name' at row 1 
May 17 14:01:47 mail roundcube: <f093uvfo> [5 ERR] Error adding addressbook from preset addressbookname: [1406] Data too long for column 'name' at row 1 

after alter table carddav_addressbooks modify column name VARCHAR(255); all is fine. Maybe the SQL init could be changed to varchar(255) for the name attribute?

thanks!

[mstilkerich]

Hi, yes, I can change it to a TEXT column to lift that limit. The name column is not used in any index, so it should not be an issue.

[chaos-prevails]

Hi, yes, I think TEXT or a long varchar should be sufficient. Thanks for updating!