Greetings: I have a task to upgrade an old OTRS server which is on an obsolete OS (Ubuntu server 10.04, believe it or not) and an obsolete OTRS version (3.0.11). I'm doing all the modifications on a dev server I built just for this purpose, so if it blows up, no worries. Prod server specs - Ubuntu 10.04 LTS server, MySQL (Amazon EC2 instance) Dev server specs - Ubuntu 12.04 LTS server, MySQL 5.5.54 The object of the exercise is to get OTRS re-deployed on a new server with a supported OS, supported database version. I am using an older version of server for the dev OS just to get the upgrades through 3.x versions done, will move to a current LTS version server OS (18.04 LTS) and current database server version, and current OTRS version. Running the DBUpdate-to-3.1.mysql.sql script I saw some errors at the end of the script where the Foreign Key Constraints were added. ERROR 1005 (HY000): Can't create table 'table `otrs301`.`#sql-4e5_8d`' (errno: 150) . I was able to clear up the error by manually running the individual ALTER TABLE statements after running SET FOREIGN_KEY_CHECKS=0; prior to running the sql script (reset this to 1 afterward). The statements yielding errors were the following: [code] ALTER TABLE gi_webservice_config ADD CONSTRAINT FK_gi_webservice_config_create_by_id FOREIGN KEY (create_by) REFERENCES users (id); ALTER TABLE gi_webservice_config ADD CONSTRAINT FK_gi_webservice_config_change_by_id FOREIGN KEY (change_by) REFERENCES users (id); ALTER TABLE gi_webservice_config ADD CONSTRAINT FK_gi_webservice_config_valid_id_id FOREIGN KEY (valid_id) REFERENCES valid (id); ALTER TABLE gi_webservice_config_history ADD CONSTRAINT FK_gi_webservice_config_history_config_id_id FOREIGN KEY (config_id) REFERENCES gi_webservice_config (id); ALTER TABLE gi_webservice_config_history ADD CONSTRAINT FK_gi_webservice_config_history_create_by_id FOREIGN KEY (create_by) REFERENCES users (id); ALTER TABLE gi_webservice_config_history ADD CONSTRAINT FK_gi_webservice_config_history_change_by_id FOREIGN KEY (change_by) REFERENCES users (id); ALTER TABLE gi_debugger_entry ADD CONSTRAINT FK_gi_debugger_entry_webservice_id_id FOREIGN KEY (webservice_id) REFERENCES gi_webservice_config (id); ALTER TABLE gi_debugger_entry_content ADD CONSTRAINT FK_gi_debugger_entry_content_gi_debugger_entry_id_id FOREIGN KEY (gi_debugger_entry_id) REFERENCES gi_debugger_entry (id); ALTER TABLE gi_object_lock_state ADD CONSTRAINT FK_gi_object_lock_state_webservice_id_id FOREIGN KEY (webservice_id) REFERENCES gi_webservice_config (id); ALTER TABLE smime_signer_cert_relations ADD CONSTRAINT FK_smime_signer_cert_relations_create_by_id FOREIGN KEY (create_by) REFERENCES users (id); ALTER TABLE smime_signer_cert_relations ADD CONSTRAINT FK_smime_signer_cert_relations_change_by_id FOREIGN KEY (change_by) REFERENCES users (id); ALTER TABLE dynamic_field_value ADD CONSTRAINT FK_dynamic_field_value_field_id_id FOREIGN KEY (field_id) REFERENCES dynamic_field (id); ALTER TABLE dynamic_field ADD CONSTRAINT FK_dynamic_field_create_by_id FOREIGN KEY (create_by) REFERENCES users (id); ALTER TABLE dynamic_field ADD CONSTRAINT FK_dynamic_field_change_by_id FOREIGN KEY (change_by) REFERENCES users (id); ALTER TABLE dynamic_field ADD CONSTRAINT FK_dynamic_field_valid_id_id FOREIGN KEY (valid_id) REFERENCES valid (id); [/code] Afterwards I ran select * from information_schema.table_constraints where table_name = 'table_name'; for each of the affected tables and could see that all of the constraints were added correctly. I also checked the table descriptions and ran a select to return * from each of the tables - they are all empty tables, and they were created by the DBUpdate-to-3.1.mysql.sql script. All that is background information. My question is pretty simple: What are these tables for - they are empty now. Were these schema modifications for future prupose? These are the seven tables created. They're all there and the information_schema.table_constraints show the constraints were correctly applied: gi_webservice_config gi_webservice_config_history gi_debugger_entry gi_object_lock_state smime_signer_cert_relations dynamic_field_value dynamic_field I am just wondering what these empty tables are for. OTRS 3.1.21 appears to be running fine - just want to make sure this isn't something that is going to cause any future problems. Thanks, Rob Mitchell Memphis, TN