SQL HASMGR error?

Question

Oracle

Hello? I can't create a database from
"SQL. The Complete Guide 2015 " CREATE TABLE PRODUCTS (MFR_ID CHAR(3) NOT NULL, PRODUCT_ID CHAR(5) NOT NULL, DESCRIPTION VARCHAR(20) NOT NULL, PRICE DECIMAL(9,2) NOT NULL, QTY_ON_HAND INTEGER NOT NULL, primary key (MFR_ID, PRODUCT_ID) ); CREATE TABLE OFFICES (OFFICE INTEGER NOT NULL, CITY VARCHAR(15) NOT NULL, REGION VARCHAR(10) NOT NULL, MGR integer, TARGET DECIMAL(9,2), SALES DECIMAL(9,2) NOT NULL, primary key (OFFICE ) ), foreign key HASMGR(MGR)


references SALEREPS
ON DELETE SET NULL);

CREATE TABLE SALEREPS
(EMPL_NUM INTEGER NOT NULL,
AGE INTEGER,
REP_OFFICE integer,
TITLE VARCHAR(10),
HIRE_DATE DATE NOT NULL,
MANAGER integer,
QUOTA DECIMAL (9,2),
SALES DECIMAL (9,2) NOT NULL,
primary key ( EMPL_NUM),
foreign key (MANAGER)
references SALESREPS
ON DELETE SET NULL,
foreign key WORKSIN (REP_OFFICE)
references OFFICES
ON delete SET NULL);

create TABLE CUSTOMERS
(CUST_NUM INTEGER NOT NULL,
COMPANY VARCHAR (20) NOT NULL,
CUST_REP INTEGER,
CREDIT_LIMIT DECIMAL(9,2),
primary key (CUST_NUM),
foreign key HASREP (CUST_REP)
references SALESREPS
ON delete SET null);

CREATE TABLE ORDERS
(ORDER_NUM INTEGER NOT NULL,
ORDER_DATE DATE NOT NULL,
CUST INTEGER NOT NULL,
REP INTEGER,
MFR CHAR(3) NOT NULL,
PRODUCT CHAR(5) NOT NULL,
QTY INTEGER NOT NULL,
AMOUNT DECIMAL (9,2) NOT NULL,
primary key (ORDER_NUM),
foreign key PLACEDBY (CUST)
references CUSTOMERS
ON DELETE CASCADE,
foreign key TAKENBY (REP)
references SALEREPS
ON DELETE SET NULL,
foreign key ISFOR (MFR, PRODUCT)
REFERENCES PRODUCTS
ON DELETE RESTRICT);

I created tables without keys and with the ALTER command I create keys too, the same error

Answer 1

The table referenced by the foreign key must exist at the time the key is created (i.e. must have been created earlier).
That is it would be necessary to change the order of creation of tables. First create SALEREPS , and only then OFFICES ...
---
But in general, the structure is kind of crazy. One table has FK to another, which has FK to the first one... somehow there is no logic at all.
And simply by resorting the order of creating tables, this is not treated. First all tables, then all foreign keys is the only solution... but first you need to understand the logic of table dependencies.
---
And this... always specify exactly the field that the foreign key should refer to. Don't rely on silence.

Answer 2

created SALEREPS, then OFFICES
Msg 102, Level 15, State 1, Line 14
Incorrect syntax near 'WORKSIN'.