Here’s a snipped from my syslog. It seems during migration the creation of new columns is not complete and causes issues.
Dec 7 19:02:50 otrs-dev ?LogPrefix?-72[17529]: [Error][Kernel::System::MigrateFromOTRS::CloneDB::Driver::mysql::AlterTableAddColumn][Line:295]: Could not execute SQL statement: ALTER TABLE article ADD a_subject (65535).
Dec 7 19:02:50 otrs-dev ?LogPrefix?-72[17529]: [Error][Kernel::System::MigrateFromOTRS::CloneDB::Driver::mysql::AlterTableAddColumn][Line:291]: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‚(65535)‘ at line 1, SQL: ‚ALTER TABLE article ADD a_message_id (65535)‘
Dec 7 19:02:50 otrs-dev ?LogPrefix?-72[17529]: [Error][Kernel::System::MigrateFromOTRS::CloneDB::Driver::mysql::AlterTableAddColumn][Line:295]: Could not execute SQL statement: ALTER TABLE article ADD a_message_id (65535).
Dec 7 19:02:50 otrs-dev ?LogPrefix?-72[17529]: [Error][Kernel::System::MigrateFromOTRS::CloneDB::Driver::mysql::AlterTableAddColumn][Line:291]: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‚(65535)‘ at line 1, SQL: ‚ALTER TABLE article ADD a_in_reply_to (65535)‘
Dec 7 19:02:50 otrs-dev ?LogPrefix?-72[17529]: [Error][Kernel::System::MigrateFromOTRS::CloneDB::Driver::mysql::AlterTableAddColumn][Line:295]: Could not execute SQL statement: ALTER TABLE article ADD a_in_reply_to (65535).
Dec 7 19:02:50 otrs-dev ?LogPrefix?-72[17529]: [Error][Kernel::System::MigrateFromOTRS::CloneDB::Driver::mysql::AlterTableAddColumn][Line:291]: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‚(65535)‘ at line 1, SQL: ‚ALTER TABLE article ADD a_references (65535)‘
Dec 7 19:02:50 otrs-dev ?LogPrefix?-72[17529]: [Error][Kernel::System::MigrateFromOTRS::CloneDB::Driver::mysql::AlterTableAddColumn][Line:295]: Could not execute SQL statement: ALTER TABLE article ADD a_references (65535).
Dec 7 19:02:50 otrs-dev ?LogPrefix?-72[17529]: [Error][Kernel::System::MigrateFromOTRS::CloneDB::Driver::mysql::AlterTableAddColumn][Line:291]: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‚(16777215)‘ at line 1, SQL: ‚ALTER TABLE article ADD a_body MEDIUMTEXT (16777215)‘
Dec 7 19:02:50 otrs-dev ?LogPrefix?-72[17529]: [Error][Kernel::System::MigrateFromOTRS::CloneDB::Driver::mysql::AlterTableAddColumn][Line:295]: Could not execute SQL statement: ALTER TABLE article ADD a_body MEDIUMTEXT (16777215).
Dec 7 19:02:50 otrs-dev ?LogPrefix?-72[17529]: [Error][Kernel::System::MigrateFromOTRS::CloneDB::Driver::Base::DataTransfer][Line:797]: Unknown column ‚a_from‘ in ‚field list‘, SQL: ‚INSERT INTO otobo.article (id, ticket_id, article_type_id, article_sender_type_id, a_from, a_reply_to, a_to, a_cc, a_subject, a_message_id, a_in_reply_to, a_references, a_content_type, a_body, incoming_time, content_path, valid_id, create_time, create_by, change_time, change_by, a_message_id_md5)#012 SELECT id, ticket_id, article_type_id, article_sender_type_id, a_from, a_reply_to, a_to, a_cc, a_subject, a_message_id, a_in_reply_to, a_references, a_content_type, a_body, incoming_time, content_path, valid_id, create_time, create_by, change_time, change_by, a_message_id_md5#012 FROM otrs.article#012‘
mysql –version
mysql Ver 15.1 Distrib 10.3.25-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
Please excuse the late reply, we are currently a bit stretched with answering OTOBO related queries on all channels.
You are right about the first error, but this query should only be made if an additional column has been added to the table „Article“ in OTRS and emigrates between different databases. However, we also found a bug that was fixed in 10.0.7.
In general, we have fixed a few more bugs in 10.0.7. This version will be released at the beginning of next week and hopefully your second bug will be fixed then. If this is not the case, please contact us briefly at hello@otobo.de so that we can analyse and fix the error together in a short remote session.
Is there’s a path to run migrate.pl by command line? I am over VPN, it takes hours, then disconnection fails and I apparently have to restart the hours …
yes there is, kind of, if you are using OTOBO with mysql that is. (I saw that we really have to update the migration tutorial. We are working on this quite a bit, still, and the documentation isn’t really keeping up, atm…)
Basically instead of migrating the database via migration.pl, this step can be done by hand, and then be skipped in the web interface. To do this, you have to run
scripts/backup.pl -t migratefromotrs --db-name otrs --db-host 127.0.0.1 --db-user otrs --db-password "secret_otrs_password"
which will create a directory with a couple of sql-files, which have to be imported into the OTOBO-database in the following order: 1. _pre; 2. _schema_for _otobo; 3. _data; 4. _post; For docker this would be done via:
You should do this, right before running migration.pl (after setting secure mode=0!), because the system won’t be usable from here on, until after the migration. Within the migration, at the step where you normally set up and test the OTRS db, you can then check the checkbox „skip db migration“. The migration will for the most part play out the same, and currently there is no way around it, but the time intensive step of copying the db will be skipped.
(If you run into errors in the steps after the db migration, and the script stops, sometimes they can be resolved by hand (with the current version we are aware of a potential problem with the web services, which will be fixed in OTOBO 10.0.8, which will be released this week) and more often than not, you can then just restart the migration from the point it failed before. Even if not, though, having the sql files should speed up doing it again, if something doesn’t work out.)
If you need further help, feel free to contact us directly,
Sven
This reply was modified 2 years, 3 months ago by Sven Oesterling.
Our website uses cookies. Cookies are tiny text files which are saved in your web browser or by your web browser on your device when you access websites. They contain a characteristic character sequence allowing to clearly identify your browser upon your next visit to the website.
You can prevent the setting of cookies at any time by making the appropriate setting in your internet browser. Cookies that have already been set can be deleted manually or automatically at any time. This is possible in all common internet browsers. If the setting of cookies is deactivated in the browser, not all functions of the website may be fully usable.
We deliberately use very little cookies.
Detailed information can be found in section 4 of our Privacy Policy.
Necessary cookies
Essential Cookies are necessary to deliver this website and some of its features correctly.
For this reason, we do not provide any opportunity here to disable them.
Notwithstanding this, you can deactivate all Cookies in your Browser Settings at any time. Please be aware, however, that this might have an impact on the functionality of this website.
More information about the cookies to be set and how long they will be stored can be found in section 4 of our Privacy Poliy: Privacy Policy.
Google Analytics' Cookies
When you visit this website, Google Analytics sets cookies on your system. This will help us analyse how you use our website ans tailor it to the needs of our visitors. Your IP address will be automatically anonymised (IP anonymisation and deactivation of your User ID). Therefore, we cannot trace which data a certain user is accessing. The data are not saved together with any other personal user data.
You can deactivate tracking in your browser if you do not want us to be able to track your visit on our website.
Privacy Policy
Detailed information on the usage of cookies as well as our Privacy Policy can be found here: