Tag Info

New answers tagged

1

Root Cause foreign_key_checks is not a global option you can preset at startup. Why ? When you click on that link to the Documentation on foreign_key_checks, there is no chart that says it is global or session scope. Other options will specify the scope in a chart ft_boolean_syntax says Variable Scope Global ; Dynamic Variable Yes innodb_doublewrite says ...


1

I'm not sure what you are saying here. Assume the following: CREATE TABLE PARENT ( a int not null primary key ); CREATE TABLE CHILD ( b int not null primary key , a int not null , constraint fk foreign key (a) references PARENT (a) ); insert into PARENT (a) values (1),(2); -- What should the default value of a be? insert into CHILD (b) ...


-2

I am also getting the same error.I am trying to migrate from mysql to postgres, while restoring into postgres its showing the constraint error. Table1 : column user_login has an entry for admin user.(It has an entry for admin) Table 2: column user_login refers the same column in table1. But its showing an error. ERROR: insert or update on table "table2" ...


1

It's a foreign key error (Error: 1025 | errno: 150) you can find out using perror: root@onare:/home/onare# perror 1025 MySQL error code 1025 (ER_ERROR_ON_RENAME): Error on rename of '%-.210s' to '%-.210s' (errno: %d) root@onare:/home/onare# perror 150 MySQL error code 150: Foreign key constraint is incorrectly formed You can get more details about what ...


0

Although foreign key names can be anything, it's actually a good practice to follow the convention of putting the table name first. The most important reason for this is that foreign key names must be globally unique (contrarily to index names). So, by following this convention, foreign key names only have to be unique within each table. Personally, I use ...


7

Using OPTION (LOOP JOIN) isn`t suitable since it costs almost 15% more than MERGE JOIN The cost percentages displayed in showplan output are always optimizer model estimates, even in a post-execution (actual) plan. These costs likely do not reflect actual runtime performance on your particular hardware. The only way to be sure is to test the ...


1

Your best bet is likely going to be to create a single child table that references all three of the other tables onto a single GAC_id. So you'd end up with something more like this: create table gac ( GAC_id, accelerometer_id, loadcell_id, potentiometer_id, primary key (GAC_id), foreign key (accelerometer_id) refrences ...


1

Properly normalized it will have 3 tables as follows: Kid kid_id (pk) classroom_id (fk to Classroom) Teacher teacher_id (pk) name Classroom classroom_id (pk) teacher_id (fk to teacher) This way you have no duplication and no update anomalies.


0

When SQL was first developed, the idea of cascading updates and deletes made sense. In practice, they are nothing but trouble. Deleting one row of one table or updating one field of one row of one table could lock up the entire database for hours because of the cascading locks. Or generate a race condition. Plus, cascading actions are, by definition, side ...


0

I will be using MS SQL terms below but you can translate them into the DBMS that you will be using. I also made some assumptions that seemed logical, so you can drop those if they do not fit your model. I would setup the tables in the following manner: Person Table PersonID int PK FName Varchar(50) LName varchar(50) DoB Date FK Name Table Name ...


0

If the foreign key constraints don't point to any other table inside of originating database (ie, if SQL Server doesn't point to SQL Server, etc.), then I would drop those foreign keys. They aren't useful. If they do point to other tables, then perhaps you do have to copy what data is needed just to satisfy the constraint. (Ugh). Either that or re-consider ...



Top 50 recent answers are included