I have created database tables manually and i have also created foreign key constraints in tables manually without using migration. now when i am going to delete a record it giving me following error-
Integrity constraint violation: Cannot delete or update a parent row:
a foreign key constraint fails
Note: i can't use migration because database was already created.
Use ON DELETE CASCADE and ON UPDATE CASCADE on foreign keys, like:
...(create/alter Children table query)...
CONSTRAINT FK_ParentChild
FOREIGN KEY (parent_id) REFERENCES Parents(id)
ON UPDATE CASCADE ON DELETE CASCADE;
So you don't have to manually delete children before deleting the parent element. All children records will automatically delete along with the deletion of parent record.
I would suggest investigating this further by doing the follow:
On your development environment, write migrations to create the
tables from scratch 2)
Look at the generated schema and compare it
to the schema of your existing production tables
Note the
differences between the two schema and write migrations to correct
the production tables.
Note:
If you need to correct the data in the meantime and you are confident that the data integrity of your database is not at risk. You can use the following statements to drop the foreign key checks whilst you correct the data.
SET FOREIGN_KEY_CHECKS = 0;
SET FOREIGN_KEY_CHECKS = 1;
I can't stress enough, remember to turn on your foreign key checks once you are finished and do not do this on a production database. Take a copy of the database and try things locally until you are confident that your corrections are 100% safe ;)
Related
I want to migrate a Tarantool table to a different format. Currently (Tarantool 2.8), this must be done manually, by creating a new table, copying the data over, dropping the old table and renaming the new table to the old name. That also means dropping all foreign keys referencing the old table and creating new ones. But an unrelated limitation is that I can't create foreign keys on tables unless those tables are also empty.
Is there any way to solve this other than just not using foreign keys at all?
EDIT: I suppose I could emulate FKs with triggers. Are there any limitations with triggers that would make such emulation impossible?
I have created a table that has a foreign key constraint on spring-session-jdbc's spring_session table. The main motivation is that spring-session would delete the rows so that it would cascade and delete entries associated with the actual session. It became a "only works on my machine" problem because only me have had the table already in place when I start the development server. It would only work if others comment out the table first, initialize the server, then revert and do it again. Otherwise, nested exception is java.sql.SQLException: Failed to open the referenced table 'spring_session'.
I think the solution is to specify the run order of (or dependencies between) the initialization sql files. I cannot find that setting after some searching, so I am here.
schema.sql:
drop table if exists foo;
create table if not exists foo (
sid char(36) not null,
foreign key (sid) references spring_session (session_id) on delete cascade,
-- other columns and constraints
);
Possible workarounds:
Workaround #1: put an alter table add constraint statement like this in data.sql.
Workaround #2: grab spring-session-jdbc's schema.sql and put it into my schema.sql, then set spring.session.jdbc.initialize-schema=never in application.properties.
U can try flyway,it can manage your init sql files by giving them a version number. And it can record which sql have been executed, so if add another sql files, it will excute the sql you added, pass the others that have been executed.
(Laravel framework)
How to create tables in database with migrations so when I try to delete a row from a table that has its key as a foreign key somewhere in another table, I got an error from database not letting me to do that ?
Do I have to create relations in migrations where I say what are the foreign keys in my database, or is there another way using only Laravel models.
I am new with this. Thank you.
You need to remove deactivate the foreign key check so to say, I am using following function to accomplish that. First I set the Foreign key check to 0 then truncate the table and set it back to 1. Setting the foreign key check to 0 allows one to truncate the table even if there are foreign keys.
# functions to truncate users table even if there are foreign key
public static function truncateUserTable()
{
DB::statement('SET FOREIGN_KEY_CHECKS=0');
User::query()->truncate();
DB::statement('SET FOREIGN_KEY_CHECKS=1');
}
I have a migration script in between 2 different schema database. The script does 3 things:
Disable constraint
Insert record from old schema to new schema
Enable constraint
During enable constraint, it encouter ORA-02298 - Parent keys not found: at the following 2 tables:
ALTER TABLE COUNTRY ENABLE CONSTRAINT COUNTRY_FK1;
ALTER TABLE EMPLOYEE ENABLE CONSTRAINT EMPLOYEE_FK7;
Anything went wrong in the table structure definition of these 2 tables?
It appears you are migrating detail records without ensuring that all the foreign key values are present in the referenced tables. If this is the case then you need to migrate records from REGION#SOURCE_DB into REGION#TARGET_DB before you migrate the COUNTRY records.
The diagram has over 40 tables, most of them have a primary key defined.
For some reason there is this one table, which has a primary key defined, but that's being ignored when I export the model to a DDL script.
This is the "offending" key (even though it's checked it is nowhere to be found on the generated DDL script):
Has anybody had the same problem? Any ideas on how to solve it?
[EDIT] This is where the key is defined:
And this is the DDL preview (yes, the primary key shows up there):
This is what happens if I try to generate the DDL for just that table (primary key still not generated):
I was finally able to identify and reproduce the problem.
It was a simple conflict of constraints.
Table MIEMBROS had a mandatory 1 to n relationship (foreign key) from another table on its primary key column and vice-versa (there was a foreign key on MIEMBROS against the other table's primary key).
This kind of relationship between two tables makes it impossible to add a record to any of them: The insert operation will return an error complaining about the foreign key restriction pointing the other table.
Anyway I realized that one of the relationships was 0 to n so I simply unchecked the "mandatory" checkbox on the foreign key definition and everything went fine.
So, in a nutshell: The Data Modeler "fails" silently if you are defining a mutual relationship (two foreign keys, one on each table against the other table) on non nullable unique columns, by not generating the primary key of one of the tables.
Such an odd behavior, if you ask me!
"This kind of relationship between two tables makes it impossible to add a record to any of them: The insert operation will return an error complaining about the foreign key restriction pointing the other table."
Actually, if you have deferred constraints, this is not impossible. The constraints can be enforced, for example, at commit time rather than immediately at insert time.
From the Data Modeler menu under File, I used Export -> DDL File. The keys appeared in the DDL, then when I went back to the diagram and did DDL Preview, it showed all the missing stuff.