Having issues declaring a FK in Oracle 9i. I've looked at a number of examples here on SO and in some online docs (e.g. http://www.techonthenet.com/oracle/foreign_keys/foreign_delete.php) without any real luck; trying a similar syntax to that in the link generates the same error:
Error at Command Line:19 Column:4
Error report:
SQL Error: ORA-02253: constraint specification not allowed here
02253. 00000 - "constraint specification not allowed here"
*Cause: Constraint specification is not allowed here in the statement.
*Action: Remove the constraint specification from the statement.
An excerpt of the SQL itself is as below. "Line 19" refers to the line starting with CONSTRAINT
CREATE TABLE Flight (
flight_no varchar2(10) NOT NULL,
airplane_id varchar2(20) NOT NULL
CONSTRAINT flight_airplane_id_fk FOREIGN KEY (airplane_id) REFERENCES Airplane (airplane_id)
ON UPDATE RESTRICT ON DELETE RESTRICT,
dept_date date NOT NULL,
...
Alternatively, trying it without the CONSTRAINT keyword generates an error about a right parenthesis that I can't seem to see is missing.
PS: I understand ON UPDATE RESTRICT is the default behaviour in Oracle, but I prefer to be explicit wherever possible.
First off, in Oracle, there is no ON UPDATE RESTRICT or ON DELETE RESTRICT option. Those appear to be valid in other database engines but they aren't present in the constraint syntax diagram and do not appear to be valid. There is an ON DELETE clause but the only two valid options are CASCADE or SET NULL. There is no ON UPDATE clause.
If we add a comma at the end of the airplane_id definition before the constriant definition and remove the two invalid clauses, your DDL should be valid
CREATE TABLE Flight (
flight_no varchar2(10) NOT NULL,
airplane_id varchar2(20) NOT NULL,
CONSTRAINT flight_airplane_id_fk
FOREIGN KEY (airplane_id) REFERENCES Airplane (airplane_id),
dept_date date NOT NULL,
<<more columns>>
);
Put your constraint at the end:
CREATE TABLE Flight (
flight_no varchar2(10) NOT NULL,
airplane_id varchar2(20) NOT NULL,
dept_date date NOT NULL,
CONSTRAINT flight_airplane_id_fk FOREIGN KEY (airplane_id) REFERENCES Airplane (airplane_id) ON UPDATE RESTRICT ON DELETE RESTRICT
);
Related
I've just upgraded h2database from 1.4.197 to 2.1.212 and now I get an error message for one of my tables that are created when running the tests.
Error:
org.h2.jdbc.JdbcSQLSyntaxErrorException: Constraint "PRIMARY KEY | UNIQUE (PID, PARTNER)" not found; SQL statement: ... [90057-212]
Status Code: 90057
SQL File:
drop table if exists prov;
create table prov(
id bigint generated by default as identity(start with 1) not null primary key,
pid bigint not null,
parent_id bigint,
partner varchar(255),
constraint unique_uk unique(pid, parent_id, partner),
constraint foreign_fk foreign key (parent_id, partner) references prov(pid, partner)
);
This SQL file was working without a problem before upgrading the h2database to v2.1.212.
What should the query be changed with?
I've searched the status code from the error and it seems that this error is thrown when trying to drop a constraint. But I'm not quite sure If I'm actually dropping any constraints. The only thing I'm dropping is the table provider if it exists.
I'm not quite familiar with H2 databases.
There is nothing specific to H2 database, every sane database system should reject this definition, but old versions of H2 and some other database systems are less restrictive.
Referential constraints require primary key or unique constraint on referenced columns. You already have a unique constraint on (pid, parent_id, partner) columns, but your referential constraint foreign_fk references only (pid, partner), so something is wrong in definition of your table.
Most likely you need an additional unique constraint on (pid, partner).
Sorry, I don't well English.
CREATE TABLE Reservation(
tno NUMBER,
sno NUMBER,
cno NUMBER,
seat_no NUMBER,
Res_Date DATE,
CONSTRAINT FK_RES_TNO FOREIGN KEY (tno) REFERENCES Theater(tno),
CONSTRAINT FK_RES_SNO FOREIGN KEY (sno) REFERENCES Screen(sno),
CONSTRAINT FK_RES_CNO FOREIGN KEY (cno) REFERENCES T_Customer(cno),
CONSTRAINT PK_RESERVATION PRIMARY KEY (tno,sno,cno)
--CONSTRAINT RES_UNIQUE UNIQUE (cno)
);
I Write Oracle Table.
But throw me Error "ORA-02270"
I don't know come to me this message.
Could you tell me some advise?
There would be multiple reasons for having this error,
You may have same primary key already, which might be disabled
Composite primary key in the table may not provide you the unique (this error many happen only when the table is ALTERED, since its new table, this logical check can be ignored)
I'm creating a couple of Tables for an assignment.
So I created a Gardener Table and an Offering Table, with all the appropriate data types and NULL statuses, as well as the Primary Key constraint for each. In the Gardener table I've included offeringID, and vice versa.
When I try to add Foreign Key constraint offeringID to the Gardener Table I get an error.
After checking online, I realized I had forgotten to make offeringID and gardenerID in each other's tables UNIQUE, hence I altered table to add uniqueness.
Tried adding Foreign Key constraint and I get the same error. I reckon I may be understanding something wrongly, but I can't seem to put my finger on it.
Create Table Gardener
(gardenerID NUMBER(10) NOT NULL,
offeringID NUMBER(10) NOT NULL,
CONSTRAINT gardener_pk PRIMARY KEY(gardenerID)
);
Create Table Offering
(offeringID NUMBER(10) NOT NULL,
gardenerID NUMBER(10) NOT NULL,
CONSTRAINT offering_pk PRIMARY KEY(offeringID)
);
Alter Table Gardener
add CONSTRAINT offering_fk FOREIGN KEY(offeringID)
REFERENCES Offering(offeringID);
Alter Table Gardener
add Unique(offeringID);
Alter Table Offering
add Unique(gardenerID);
This is the error:
ORA-02270: no matching unique or primary key for this column-list
02270. 00000 - "no matching unique or primary key for this column-list"
Cause: A REFERENCES clause in a CREATE/ALTER TABLE statement gives a column-list
for which there is no matching unique or primary key constraint in the referenced table.
Like, I still don't get it. Isn't offeringID a Primary Key hence pointing to it from Gardener shouldn't be an issue still?
Since you're trying to add a a foreign key constraint for offering.offeringID column within the Gardener table, whereas that column has no unique/primary key key when you try to add a foreign key. i.e. operation stops at the 3rd command.
So, just exchange the order of commands as :
Alter Table Gardener
add Unique(offeringID); -- should be prior to the below command
Alter Table Gardener
add CONSTRAINT offering_fk FOREIGN KEY(offeringID)
REFERENCES Offering(offeringID);
Demo
Is any way, how to create table with CHECK (or maybe TRIGGER?), that will check, if inserted value is already in another table?
Example
CREATE TABLE Employee(
Name VARCHAR(10),
Adress VARCHAR(20)
);
CREATE TABLE Section(
Section_name VARCHAR(10),
Managers_name VARCHAR(10)
);
And I want to check, that value inserted to Managers_name is already in Employee, if it isnt, then print error.
I found any ways, how it could be done, but everything I tried in Oracle, didnt work.
Add a PRIMARY KEY constraint to the employee table and a FOREIGN KEY constraint to the section table:
CREATE TABLE Employee(
Name VARCHAR(10) CONSTRAINT Employee_Name_PK PRIMARY KEY,
Adress VARCHAR(20)
);
CREATE TABLE Section(
Section_name VARCHAR(10),
Managers_name VARCHAR(10)
CONSTRAINT section_manager_fk REFERENCES Employee( Name )
);
Check constraint is, as explained by mt0, devoted to single table.
Trigger is to be avoided for consistency reasons: while you're selecting a record, another session might be in the process of deleting it.
The Foreign Key is the correct way to implement it: Trap FK constraint violation in your code (ORA-02291 i guess), search for "section_manager_fk" in the message and finally rewrite a user-friendly error message.
In Oracle, if you try to explicitly define the schema for a constraint in a CREATE TABLE statement it will result in a ORA-00904: : invalid identifier error:
CREATE TABLE SCHEMA1.MY_TABLE
(
TABLE_ID NUMBER(5)
, FLAG VARCHAR2(1) DEFAULT 'F'
, CONSTRAINT SCHEMA1.MY_TABLE_PK PRIMARY KEY (TABLE_ID) -- Parser doesn't like 'SCHEMA1'
, CONSTRAINT SCHEMA1.MY_TABLE_FLAG_CK CHECK (FLAG IN ('T', 'F')) --Same issue
);
This is no big deal because the constraint OWNER defaults to the same schema as defined in the CREATE TABLE declaration (or at least in the schema you are signed into - my accounts don't have the rights to validate). This can be confirmed by pulling up the constraint in ALL_CONSTRAINTS or DBA_CONSTRAINTS and viewing the OWNER value (which would read SCHEMA1 for the two constraints above).
But if you then follow up this statement with a second duplicate statement under a different schema:
CREATE TABLE SCHEMA2.MY_TABLE
(
TABLE_ID NUMBER(5)
, FLAG VARCHAR2(1) DEFAULT 'F'
, CONSTRAINT MY_TABLE_PK PRIMARY KEY (TABLE_ID) --This constraint already exists
, CONSTRAINT MY_TABLE_FLAG_CK CHECK (FLAG IN ('T', 'F')) --This one too
);
this results in an ORA-00955: name is already used by an existing object error.
My understanding of constraints are that they are just another object on the database which I would have assumed were subject to the same ownership rules with which I'm familiar. But based on the behavior above it is clear that they do not behave like most objects on the database.
Questions
What is it about constraints that requires their names be unique across all schemas (unlike other objects on the database)?
Does anyone know the technical reason for this naming requirement?
For context, I've run into a scenario at work where I had wanted to store duplicate names under different schemas (don't ask... it was inherited duplication and I'm just trying to stay consistent until I have funding to refactor). Now, I realize that I can very simply add the schema to the name and bypass this problem quickly but this rubs my OCD the wrong way so I'd like to better understand just why I can't do what I'm trying to do.
----------------------------- UPDATE ---------------------------
Okay... so I'm a fool. Please note that the above scenario cannot be repeated given a clean environment. After trying to reproduce the issue, I now realize what happened.
I'm currently working on cleaning up some DDL statements in preparation for a production release. I'm not the only developer in this environment and my offshore team has been working on these same tables. I have been editing some preexisting DDL scripts in preparation for a production release and had added some needed constraints to a few CREATE TABLE statements.
It would appear that I had failed to run my DROP scripts before running the second statement in SCHEMA2. My confusion was due to thinking that I was getting the ORA-00955 error because of the new constraints I was adding when in actuality it was because the SCHEMA2.MY_TABLE already existed in this environment. This misdiagnosis was compounded by me changing my constraint names and then rerunning all of my scripts successfully (as I must have run my DROP statements in all schemas before retesting). As a result I thought that I had observed unforeseen behavior when I really had not.
Thank you to everyone who commented for showing me the light!
What's missing in your question is the user under which you run the script. But here's a little experiment.
Connected to the database as user system. I have schemas NGM42 and NGM41 available for the experiment.
CREATE TABLE NGM41.MY_TABLE
(
TABLE_ID NUMBER(5)
, FLAG VARCHAR2(1) DEFAULT 'F'
, CONSTRAINT MY_TABLE_PK PRIMARY KEY (TABLE_ID) -- Parser doesn't like 'SCHEMA1'
, CONSTRAINT MY_TABLE_FLAG_CK CHECK (FLAG IN ('T', 'F')) --Same issue
);
CREATE TABLE NGM42.MY_TABLE
(
TABLE_ID NUMBER(5)
, FLAG VARCHAR2(1) DEFAULT 'F'
, CONSTRAINT MY_TABLE_PK PRIMARY KEY (TABLE_ID)
, CONSTRAINT MY_TABLE_FLAG_CK CHECK (FLAG IN ('T', 'F'))
);
Both statements run succesfully. So what happened to the constraints?
select owner,constraint_name from all_constraints
where constraint_name in ('MY_TABLE_PK','MY_TABLE_FLAG_CK')
NGM42 MY_TABLE_PK
NGM41 MY_TABLE_PK
NGM41 MY_TABLE_FLAG_CK
NGM42 MY_TABLE_FLAG_CK
The constraints are created in the same schema as the table. As you can see they do not need to be globally unique in the database.