As you can see in the picture, I have the tables. The mistake I got is as follows: From the airport table, the primary key should go to both fields in the flight table. I get an error when I do this to both the stay airport and the landing airport. How do I solve this?
Error: - Unable to create relationship 'FK_a.ucus_a.havalimanlari1'.
Introducing FOREIGN KEY constraint 'FK_a.ucus_a.havalimanlari1' on table 'a.ucus' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Could not create constraint or index. See previous errors.
Related
I am trying to create a table serving as a log of calculations. Upon entering data, I would like to check if the data entered in some columns exists in another table. In this other table, the data is in fact the primary key, so I could create a FOREIGN KEY constraint - however, I only want the consistency with this "foreign key" to be checked once for each row after newly inserting it, but never again. I do not want to create an actual parent-child relationship of these tables, as the 'child' should keep records regardless of changes to the 'parent'.
I have attempted to implement this using a CHECK constraint, e.g.:
CONSTRAINT CSTR_CALCLOG1 CHECK (USERID in(select USERID from USER_TABLE))
Resulting in the error:
ORA-02251: subquery not allowed here
It seems that check constraints are fairly limited as described here, and therefore not the right tool for the job:
http://www.dba-oracle.com/t_oracle_check_constraint.htm
How can this be achieved?
I have two tables, a Photographer and an Influences table. In the Influences table, a Photographer is able to influence another Photographer.
Relational Schema:
Here is my Diagram in SQL:
Instance Example:
My issue is when I try to delete Photographer Tom, since he influences Jason (as shown in Influences table), I get a error stating:
The DELETE statement conflicted with the REFERENCE constraint "FK_Influences_Photographer1". The conflict occurred in database "jma59", table "dbo.Influences"
If Tom was in the column EPName of the Influences table, I have no issue deleting it. I know that this is a foreign key issue but I am not sure how to handle this situation. I created two separate foreign keys that reference to the Photographer primary key. But the problem is that I cannot make it so that both foreign keys cascade on update and delete.
First foreign key is EPName and EPBDate referencing to PName and PBDate of Photographer
Second foreign key is RPName and RPBDate referning to PName and PBDate of Photographer as well.
The error is:
Unable to create relationship 'FK_Influences_Photographer1'. Introducing FOREIGN KEY constraint 'FK_Influences_Photographer1' on table 'Influences' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Any advice is greatly appreciated!
You could consider using a Trigger rather than a cascading delete to enforce referential integrity: https://support.microsoft.com/en-gb/help/321843/error-message-1785-occurs-when-you-create-a-foreign-key-constraint-tha
I used a plugin in Intellij to generate SQL and it looks correct but I keep getting an error saying violated - parent key not found
Added for clarity: 'LOCAL.fOO_LANGUAGE_FK) violated - parent key not found'
To make it I used this:
create table fOO
(
Foo_ID NUMBER not null
constraint CAMPAIGN_PK
primary key,
You are attempting to insert a record into a table which references 5 other tables:
SHOP
SEVERITY
CAMPAIGN_USAGE
LAYOUT
SALE_QUALIFICATION
These references are enforced by constraints. These constraints are rules that the database enforces on your data, and it's based on your data model.
By comments shared in your follow-up, you also have a LANGUAGE table references by your SHOP table.
So to insert a record into your table, you have to make sure the referenced values are all present in your other 5 or more tables.
If you cannot insert the data in the correct order, it's quite common when building out your schema, to create the foreign key constraints DISABLED, INSERT all the data, COMMIT, and then ENABLE all the constraints back on.
To disable a constraint, for example 'CAMPAIGN_SHOP_FK', you can
alter table CAMPAIGN disable constraint CAMPAIGN_SHOP_FK;
It is VITAL that you enable your constraints back if you do not want orphaned rows in your data model.
Some folks will mistakenly rely on their software to ensure their data is 'clean'. If you do this, then you are betting your software is error free AND that no one is in the database touching your data. Both cases are rarely, if ever, true.
I went over a legacy database and found a couple of foreign keys that reference a column to itself. The referenced column is the primary key column.
ALTER TABLE [SchemaName].[TableName] WITH CHECK ADD
CONSTRAINT [FK_TableName_TableName] FOREIGN KEY([Id])
REFERENCES [SchemaName].[TableName] ([Id])
What is the meaning of it?
ALTER TABLE [SchemaName].[TableName] WITH CHECK ADD
CONSTRAINT [FK_TableName_TableName] FOREIGN KEY([Id])
REFERENCES [SchemaName].[TableName] ([Id])
This foreign key is completely redundant and pointless just delete it. It can never be violated as a row matches itself validating the constraint.
In a hierarchical table the relationship would be between two different columns (e.g. Id and ParentId)
As for why it may have been created quite likely through use of the visual designer if you right click the "Keys" node in object explorer and choose "New Foreign Key" then close the dialogue box without deleting the created foreign key and then make some other changes in the opened table designer and save it will create this sort of redundant constraint.
In some cases this is a preferred way to reduce redundancy in your model. In using the self referencing foreign key (as shown in you example) you create a hierarchical relationship between rows in your table. Pay attention to what happens when you delete a row from the table, cascading on delete might remove rows you still want.
Using these sort of keys moves some of the data validation to the DB model as opposed to making this a responsibility of the program/programmer. Some outfits prefer this way of doing things. I prefer to make sure programs and programmers are responsible - data models can be hard to refactor and upgrade in production environments.
What could possibly caused a FK error? I'm inserting an 'Activity' record into a database that has a 'StaffId' field on (FK with Staff table), I've looked for the staffId in question (no white spaces etc.) and it DOES exist. What else can cause an error with a foreign key field?
EDIT: Error:
The INSERT statement conflicted with the FOREIGN KEY constraint
"FK_Activities_Staff". The conflict occurred in database
"DataWarehouseB", table "dbo.Staff", column 'StaffId'. The statement
has been terminated.
SQL Foreign Key documentation says
If the database schema contains foreign key errors that require
looking at more than one table definition to identify, then those
errors are not detected when the tables are created. Instead, such
errors prevent the application from preparing SQL statements that
modify the content of the child or parent tables in ways that use the
foreign keys. Errors reported when content is changed are "DML errors"
and errors reported when the schema is changed are "DDL errors". So,
in other words, misconfigured foreign key constraints that require
looking at both the child and parent are DML errors. The English
language error message for foreign key DML errors is usually "foreign
key mismatch" but can also be "no such table" if the parent table does
not exist. Foreign key DML errors are may be reported if:
The parent table does not exist.
The parent key columns named in the foreign key constraint do not exist.
The parent key columns named in the foreign key constraint are not the primary key of the parent table and are not subject to a
unique constraint using collating sequence specified in the CREATE
TABLE.
The child table references the primary key of the parent without specifying the primary key columns and the number of primary key
columns in the parent do not match the number of child key columns.
Some DBs might also support using a non-unique index as a foreign key reference,