When I use the Grails Database Migration Plugin and run a dbm-gorm-diff (for example, after installing the Spring Security Facebook plugin) I have been getting problems like:
Error: Error executing SQL CREATE INDEX `FK609FD5A460CFCC39` ON `facebook_user`(`user_id`): Incorrect index name 'FK609FD5A460CFCC39'
It looks like the index in question is both a FK constraint and is then reused as an index later in the generated upgrade script. If i change the name, thus removing the duplicate, everything works fine. I am using Mysql. Am I doing something wrong?
Thanks.
I just found out that if I edit changelog.groovy to place addForeignConstraint's after createIndex's, it works like a charm. Yet another problem in the changelog generation script I guess.
I suspect this is actually related to MySQL and not to the plugin itself. See this bug: http://bugs.mysql.com/bug.php?id=55465
Sebastien's answer is a work around.
As per this question/answer, MYSQL automatically indexes foreign key columns. So when you add a foreign key constraint, you don't need to also define an index. I use the db migration plugin and just remove the 'index' entries for foreign keys that the dbm-gorm-diff generates.
I think this is a bit better than changing the name, since that likely creates more than one index on the same column which is just a waste of resources.
Related
I am trying to alter table product to add a constraint of type foreign key for field petCat_ID so that it references table petCategory(ID). I just created table petCat_ID and i am getting a "Cannot add or update a child row" error.
This is the commands I performed to get this error:
Alter table product
-> ADD CONSTRAINT FK_petCatID
-> FOREIGN KEY (petCat_ID)
-> REFERENCES productCategory(ID);
Any help or tips would be greatly appreciated! Note: petCat_ID is in table product and productCategory is a different table.
In my comments I've mentioned that I need a clearer idea of what kind of database structure you have, but I have a series of things that will help you work through the problem you're having.
If an ALTER statement isn't working, and you have good syntax, it is because what you are doing conflicts with an already present rule.
Sometimes, doing a DROP TABLE command, followed by creating the table again can fix problems. This can be problematic if there are dependencies that keep you from dropping the table.
When things get dire, try looking at the script you used to make the DB in the first place. Modify it and see if you can get the properties you want. Once you do, make a new database table structure and migrate your table entries over to the new database from the old one.
I made a github repository here wherein I made a third normal form version of what the customer facing Amtrack database would look like, and even wrote scripts to add data to the tables, with examples. There are images showing the ER structure. I included my creation script, broken into each table's creation in specific order. It should be a good reference for how to assign table relationships, and that will give you a good idea of what you can alter. Disclaimer I wrote it for SSMS, but I don't believe I used anything SSMS specific I THINK that code should work in MySQL.
i want to know if it's possible to drop a table fragment that is not letting me perform a restore with the NDB_RESTORE tool.
When i run the restore, it throws the following error:
Create table db_died_maestro/def/NDB$FKM_3194_0_mae_tipo_reg_evaluacion failed: 721: Schema object with given name already exists
Restore: Failed to restore table: db_died_maestro/def/NDB$FKM_3194_0_mae_tipo_reg_evaluacion ... Exiting
NDBT_ProgramExit: 1 - Failed
I have already drop the DB_DIED_MAESTRO database previous to run the restore, but this fragment is not being dropped along with the database.
I have check that the fragment is in the database catalog using this querys:
*select * from ndbinfo.operations_per_fragment
where fq_name like 'db_died_maestro%'*
query result
And this query:
*select * from ndbinfo.memory_per_fragment
where fq_name like '%FKM_3194_0_mae_tipo_reg_evaluacion'*
query 2 result
This fragment was created on a previous run of the NDB_RESTORE tool. Please help me.
The table is a foreign key 'mock' table (indicated by the name NDB$FKM prefix).
Foreign key mock tables are created transiently in some cases to implement the foreign_key_checks = 0 feature of MySQL. This feature requires storage engines to support unordered creation of tables with partially defined foreign key constraints which can be abritrarily enabled (without revalidation) at a later time.
Foreign key mock tables are normally entirely managed by the Ndb storage engine component of MySQL, and so should not be visible unless there has been a failure or bug of some kind.
If you can share information about activities occurring before this problem then that would help us understand how this happened and whether it can be avoided.
As a workaround it should be possible for you to use the ndb_drop_table utility to drop this table, before re-attempting the failing restore. You may have to escape the $ in the name passed as a command line argument from a shell. Probably you should check for any other NDB$FKM tables in a similar situation.
I am working on a web application using entity framework and MySql. I have created some views and tables in my database but unfortunately ADO.Net data modal is not including the views. I have recreated my data modal but still views are missing. I have applied several solutions which i have found on different forums some one was suggesting to restart visual studio, Even some people was asking to restart the PC. but its not working for me.
Finally i have managed to solve this problem by adding a primary key column in my select statement.It was obvious that we must need a primary key to add our table in modal but as views have no primary key that's why i was confused. In short we must have to include at least one primary key column of a table in select statement.
I have a database that I built a while back. Every table in the database is InnoDb. Several tables had foreign key constraints, and I set them up for On Delete = Cascade. When I was using an earlier version of phpmyadmin, working with these was simple: I'd just go to the Structure tab of a table, click the Relation View link, and as long as I had the correct indexes set up on the correct columns, I could set the foreign keys as I saw fit.
Since upgrading to version 4, it's become a nightmare. For some tables, I go to the relation view and everything is just fine. But for others--even when they already have foreign key constraints set--I can't see any options for working with them.
To make matters worse, I've even tried dropping the indexes and re-adding them, only to be given the following error: Cannot drop index [index_name]: needed in a foreign key constraint. So unless I'm mistaken, the constraint is there, but phpmyadmin is refusing to show it to me.
Is there something I have to do to make them show up again? This is extremely frustrating to say the least: something that worked just fine before now does not thanks to an upgrade.
OK, after playing around with the tables a bit, I figured out what's going on. The only time the foreign key constraint options don't show up are when the table names contain capital letters. Very frustrating to say the least.
I just filed a bug report for phpmyadmin: https://github.com/phpmyadmin/phpmyadmin/issues/11461
It should be an easy fix.
happened to me because i used '&" in the database name.
In my case it is that I used two columns (A and B) both as foreigns keys to other tables then I also used a composite unique for ([A, B]), phpMyAdmin does not show the existed foreign index of column A but does show that for column B.
My system version are as follows:
Server version: 5.7.30 - MySQL Community Server (GPL)
I'm writing some code to inspect a MySQL database structure, and need information about Foreign Key constraints (on InnoDB tables).
There are two ways I know of to do this:
Parse the results of SHOW CREATE TABLE X
Use INFORMATION_SCEMA.REFERENTIAL_CONSTRAINTS
Unfortunately option two requires MySQL 5.1.16 or later, so I can't use it unless/until I can convince our server guy to update, And while I can probably get away with option 1, it feels messy and without writing a full SQL parser I wouldn't feel sure my code would always work with any table.
Is there another way of getting at this information?
Thanks
From the MySQL 5.0 manual online:
You can also display the foreign key constraints for a table like
this:
SHOW TABLE STATUS FROM db_name LIKE 'tbl_name';
The foreign key constraints are listed in the Comment column of the
output.
Poster indicates that this doesn't provide ON UPDATE and ON DELETE information which is an important part of foreign key behavior.
Another option:
Since you control the code involved, is it possible to set up another MySQL instance in the same environment which is version 5.1+? If so, let's call that instance dummy. Run the SHOW CREATE TABLE on the live database. Then, on dummy run a DROP TABLE IF EXIST followed by the output from the SHOW CREATE TABLE query.
Now you can use INFORMATION_SCHEMA on the dummy database to get the information.