You are not logged in.
Hello,
Since upgrade from GLPI 9.5.4 to GLPI 10.0.3, XLSX and DOCX documents cannot be attached to tickets.
A cron email notification reports a SQL 1406 error:
SQL Error "1406": Data too long for column 'mime' at row 1 in query "INSERT INTO `glpi_documents` (`name`, `tickets_id`, `entities_id`, `is_recursive`, `documentcategories_id`, `mime`, `filename`, `filepath`, `sha1sum`, `tag`, `date_creation`, `date_mod`) VALUES ('Document ticket 31097', '31097', '0', '0', '3', 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet', 'realisation-pananc-aout.xlsx', 'XLSX/cc/aabc651758e4d48aa20031435ca3cc2ff30954.XLSX', 'ccaabc651758e4d48aa20031435ca3cc2ff30954', '50088f67-b2d8e96f-6322ee42ca4513.58776017', '2022-09-15 11:20:01', '2022-09-15 11:20:01')"
SQL Error "1406": Data too long for column 'mime' at row 1 in query "INSERT INTO `glpi_documents` (`name`, `tickets_id`, `entities_id`, `is_recursive`, `documentcategories_id`, `mime`, `filename`, `filepath`, `sha1sum`, `tag`, `date_creation`, `date_mod`) VALUES ('Document ticket 31108', '31108', '0', '0', '3', 'application/vnd.openxmlformats-officedocument.wordprocessingml.document', 'mon-ecran-pour-la-visio-de-cet-apres.docx', 'DOCX/fb/ffb2763c3c5038cc0b459b65751e0606402af5.DOCX', 'fbffb2763c3c5038cc0b459b65751e0606402af5', '50088f67-b2d8e96f-63242aab64fb75.75290455', '2022-09-16 09:50:02', '2022-09-16 09:50:02')"
Mime type are too long to fit into mime column of glpi_documents table, which is varchar(30):
application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
application/vnd.openxmlformats-officedocument.wordprocessingml.document
It seems to be related to GLPI 10 upgrade, since the glpi_documents table already contains XLSX and DOCX files with a much shorter associated mime type (ie: application/vnd.openxmlformats).
Thanks for your help,
Thomas
Last edited by Thomas Williamson (2022-09-16 11:32:25)
Offline
The mime column in both glpi_documenttypes and glpi_documents should bee of length 255, not 30. Since it is 30, it shows that one or migrations may not have completed properly.
Please run the GLPI database schema check command to get a list of all database schema differences.
bin/console glpi:database:check_schema_integrity
GLPI Collaborator and Plugin Developer.
My non-English comments are automated translations. Sorry for any confusion that causes.
Mes commentaires non anglais sont des traductions automatiques. Désolé pour toute confusion qui cause.
Mis comentarios que no están en inglés son traducciones automáticas. Perdón por cualquier confusión que cause.
Offline
Hello,
Thanks for your help!
The command you suggest returns 1000+ lines, among them:
Le schéma diffère pour la table "glpi_documents".
--- Schéma de base de données attendu
+++ Schéma de base de données actuel
@@ @@
`is_deleted` tinyint NOT NULL DEFAULT 0,
`is_recursive` tinyint NOT NULL DEFAULT 0,
`link` varchar(255),
- `mime` varchar(255),
+ `mime` varchar(30),
`name` varchar(255),
`sha1sum` char(40),
`tag` varchar(255)
The column has indeed been typed with 30 characters (255 before)...
Thomas
Offline
With the database in an inconsistent state, the best solution would be manually correcting the incorrect schemas (after backing up the database).
Changing the field lengths like this column should be safe and not have any side-effects.
Other changes may be more complex.
GLPI Collaborator and Plugin Developer.
My non-English comments are automated translations. Sorry for any confusion that causes.
Mes commentaires non anglais sont des traductions automatiques. Désolé pour toute confusion qui cause.
Mis comentarios que no están en inglés son traducciones automáticas. Perdón por cualquier confusión que cause.
Offline
thank you, I had the same problem and this solved it
Offline