`display_name` varchar(25) DEFAULT '#ffffff', `courses_created` int(10) NOT NULL DEFAULT '0',
`homepage_viewable` bit(1) NOT NULL DEFAULT b'1', `phone_number` varchar(255) DEFAULT NULL, `company_id` bigint(20) NOT NULL AUTO_INCREMENT, KEY `FK82977604FE40A062` (`company_id`) USING BTREE,ĬONSTRAINT `FK8297760442C8F876` FOREIGN KEY (`module_id`) REFERENCES `module` (`module_id`)Īnd Create Table: CREATE TABLE `company` ( The tables "as is" in my database: CREATE TABLE `company_to_module` ( I cannot drop tables because this is a production database. They already have foreign keys in other columns as it is. The names do in fact exist in their respective tables. The columns are using the same type - BIGINT (20) But these same foreign key migrations are not taking on Debian.
Let's not mention that I took the SAME database that I have on the server and it migrates fine on Windows. There are no values in this table that would conflict with the foreign key I am trying to add.
#Add foreign key mysql update
> ADD CONSTRAINT `FK82977604FE40A062` FOREIGN KEY (`company_id`) REFERENCES `company` (`company_id`) ON DELETE RESTRICT ON UPDATE RESTRICT ĮRROR 1005 (HY000): Can't create table 'jobprep_production.#sql-44a5_76' (errno: 150) I went to run my migration script on my debian server, which is also using mysql 5.1, and it gives the following error: mysql> ALTER TABLE `company_to_module`
This works great on mysql 5.1 on windows for the development database. My solution was to drop all the indexes and foreign keys, rename the id columns, and then re-add the indexes and foreign keys. Obviously mysql makes this a real pain to do in my experience. I have a production database where I have renamed several column's that are foreign keys.
0 kommentar(er)
