Self Referential integrity constraint?

What is self-referential integrity constraint? Is it a foreign key where the same column acts as the parent key too.

The good old EMP table in the SCOTT schema is one example. Managers are employees, so the MGR column refers back to the EMPNO primary key. If I wanted to create my own table...
1 create table emp2 (
2 empno number primary key,
3 mgr number references emp2( empno )
4* )
SCOTT @ hp92 Local> /
Table created.Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Similar Messages

What is self referential integrity? How does it effect the Database?

Hello Gurus,
What is self referential integrity?
How could it is achieved and implemented?
and what is effect on the Database?
Thanks in advance.
~ SubbaReddy .M

Self referential integrity simple means that the parent end of a foreign key constraint is in the same table as the child end. Consider the SCOTT.EMP table. Every manager is also an employee. Hence there is a foreign key between the MGR column and the EMPNO column.
rgds, APC

How to export-import referential integrity constraints ?

Hi all
Is there any way to export only the referential integrity constraints from one user to another user ?
Suppose i am having SCOTT user which is having EMP , DEPT tables . And also I am having another user (say TEST) which also is having those EMP and DEPT table but without the referential integrity constraints . Now can i export
referential integrity constraints from SCOTT and import into TEST so that EMP,DEPT tables(in TEST) will have those referential integrity constraints which are present in SCOTT user ?
Thanks
Debashis
Bangalore

Hi,
See the BAM Enterprise Link Utilities User's Guide for additional Enterprise Link import/export capabilities not exposed via ICommand.
Regards, Stephen

Associted two table where referential integrity constraint is present

SELECT A.COLUMN_NAME,A.CONSTRAINT_NAME,B.CONSTRAINT_TYPE,A.TABLE_NAME FROM USER_CONS_COLUMNS A,USER_CONSTRAINTS B
WHERE A.OWNER=B.OWNER
AND A.OWNER='TEST'
AND A.TABLE_NAME=B.TABLE_NAME
AND A.CONSTRAINT_NAME=B.CONSTRAINT_NAME
AND A.TABLE_NAME='CN_SMSC'
from this query we can get name of the column ,const name,type and associated sigle table name.
my question is
==============
how will i get associted two table where referential integrity constraint is present

SELECT A.COLUMN_NAME,A.CONSTRAINT_NAME,B.CONSTRAINT_TYPE,A.TABLE_NAME "Detail Table", b.R_CONSTRAINT_NAME , c.TABLE_NAME "Primary table"
FROM user_CONS_COLUMNS A,user_CONSTRAINTS B, user_constraints c
WHERE A.OWNER=B.OWNER
AND A.OWNER='TEST'
AND A.TABLE_NAME=B.TABLE_NAME
AND A.CONSTRAINT_NAME=B.CONSTRAINT_NAME
and b.CONSTRAINT_type ='R'
and c.CONSTRAINT_NAME = b.R_CONSTRAINT_NAME
AND A.TABLE_NAME='CN_SMSC'

Issue with Referential Integrity check in Oracle VPD Policy

Hi,
Lets assume I have two tables - Customer and Order, with cust_id in Order table referring to primary key of Customer table.
Example Data;
Customer
cust_id Name
1 abc
2 def
3 ghi
Order
Order_id cust_id Order_type
1 1 A
2 2 A
3 1 B
Now I have policies defined on both the tables;
- for "Select, Insert, Update" queries on Customer table.
- for "Select" queries on Order Table.
Policy 1 on Order Table;
Irrespective of the user, predicate = 'Order_type = ''A'''
Policy 2 on Customer Table;
Irrespective of the user, predicate = '(select count(1) from order o where o.cust_id = customer.cust_id and o.order_type = ''B'') > 0'
My intention is to show only those customers who have atleast one order of type 'B'. And this policy works fine in case a user tries to read data from customer table. (for example, record for cust_id = 2 will not be returned as it don't have any orders of type "B")
However, when a user tries to insert record in Order Table, because of the existing referential integrity constraint, the Policy on Customer table is also getting triggered. And an exception is being raised "ORA-28113: policy predicate has error".
Could someone please explain why this is happening ?

I'm afraid, there is no such a mean.
At least I do not know about it.

Automated Solution for Integrity Constraints?

Here is the situation. I have a parent table with child rows in LIVE. A workspace is then created, and another child is added to one of the parent rows in live. Another workspace is then created, and the parent row for the first workspaces child is deleted. The user tries to merge the second workspace to LIVE, which fails with a ORA-20237 error (expected).
How do I in an automated fashion, determine what row(s) in what workspace(s) are causing the error workspace merge? This is on 10gR2.
Integrity constraint violations do not show up in the CONF views, so that doesn’t help. I need to be able to eliminate the conflicts in an automated fashion, providing notice to the owners of the workspaces that they need to go revise the parts that were forcefully removed. But to do that, I need to know how to locate the issues causing the problem so I can build a package to do this, hands off.
Example script:
SQL> create table test_parent (pk number not null, name varchar2(50),
2   CONSTRAINT test_parent_ndx PRIMARY KEY (pk));
Table created.
SQL> create table test_child (pk number not null, fk number, name varchar2(
2    CONSTRAINT test_child_ndx PRIMARY KEY (pk),
3    CONSTRAINT test_child_FK01
4   FOREIGN KEY (fk)
5   REFERENCES test_parent (pk)
6   on delete cascade);
Table created.
SQL> exec dbms_wm.enableversioning('test_parent,test_child');
PL/SQL procedure successfully completed.
SQL> insert into test_parent values (1, 'First item');
1 row created.
SQL> insert into test_parent values (2, 'Second item');
1 row created.
SQL> insert into test_child values (101, 1, 'References first item');
1 row created.
SQL> commit;
Commit complete.
SQL> select * from test_parent;
        PK NAME
         1 First item
         2 Second item
SQL> select * from test_child;
        PK         FK NAME
       101          1 References first item
SQL> exec DBMS_WM.createworkspace('1', TRUE, 'None', TRUE );
PL/SQL procedure successfully completed.
SQL> exec DBMS_WM.gotoworkspace('1');
PL/SQL procedure successfully completed.
SQL> insert into test_child values (102, 1, 'References first item');
1 row created.
SQL> commit;
Commit complete.
SQL> select * from test_parent;
        PK NAME
         1 First item
         2 Second item
SQL> select * from test_child;
        PK         FK NAME
       101          1 References first item
       102          1 References first item
SQL> exec DBMS_WM.gotoworkspace('LIVE');
PL/SQL procedure successfully completed.
SQL> exec DBMS_WM.createworkspace('2', TRUE, 'None', TRUE );
PL/SQL procedure successfully completed.
SQL> exec DBMS_WM.gotoworkspace('2');
PL/SQL procedure successfully completed.
SQL> select * from test_parent;
        PK NAME
         1 First item
         2 Second item
SQL> select * from test_child;
        PK         FK NAME
       101          1 References first item
SQL> delete from test_parent where pk = 1;
1 row deleted.
SQL> commit;
Commit complete.
SQL> select * from test_parent;
        PK NAME
         2 Second item
SQL> select * from test_child;
no rows selected
SQL> exec DBMS_WM.gotoworkspace('LIVE');
PL/SQL procedure successfully completed.
SQL> exec DBMS_WM.mergeworkspace('2', FALSE, FALSE, FALSE );
BEGIN DBMS_WM.mergeworkspace('2', FALSE, FALSE, FALSE ); END;
ERROR at line 1:
ORA-20237: integrity constraint (CVC.TEST_CHILD_FK01) violated in workspace
LIVE or one of its descendants - child record found
ORA-06512: at "WMSYS.LT", line 6009
ORA-06512: at line 1Bryan

Hi Amit,
The merge operation does result in the deletion of the row from both LIVE and the child workspace. However, this would cause the child table in the other (non-merged) workspace to have data without a corresponding parent row. We can not allow this, and so raise a referential integrity constraint violation. It is also not a conflict, as conflicts are always for rows with the same primary key, not for business conflicts or constraint violations. In the example, the inserted row in the child workspace was for a primary key that was unique within all workspaces, and so no conflict violation would be raised.
The reason it works for a non-CR workspace, is that the parent table row is still visible from the other workspace as it was not automatically deleted.
You can use the DIFF view(with SetDiffVersions) or the MW view(with SetMultiWorkspaces) to determine which rows were deleted from the parent table that you are merging. This information can then be used to find the other workspace/savepoint that is causing the violation and fix it. This could be done by removing the child row or inserting/updating the parent row prior to the other workspace being merged.
Ben

Migrating MySQL5 database to Oracle 10g - refrential integrity constraints

On migrating MySQL5 database to oracle, referential integrity constraints are not migrated to Oracle. Capture stage shows it has captured the constraints but constraints are missing from the Oracle Model. Is this a bug? If not, what I need to do to get constraints migrated.

Check out *URGENT* Does Oracle SQL Developer able to migrate tables relationships?
K.

Distributed referential integrity

Hi, I have a question. If I am on the wrong forum please direct me as I could not find a specific forum for distrituted databases and these may be a application development question.
I am implementing a simple distributed database application. At this point I am only concerned with creating two tables each on a different server. For simplicty I will name them table1 and table2. This would be the schema if the tables were not distributed and were located on the same server.
CREATE TABLE table1 (
table1_id NUMBER CONSTRAINT table1_pk PRIMARY KEY
CREATE TABLE table2 (
table2_id NUMBER,
table1_id NUMBER,
CONSTRAINTtable2_pk PRIMARY KEY (table2_id, table1_id),
CONSTRAINT table2_fk FOREIGN KEY (table1_id) REFERENCES table1(table1_id)
I have referred to the documentation in both Oracle® Database Administrator's Guide 10g Release 2 (10.2) and Oracle Database Application Developer's Guide. I know that I cannot use declarative referential integrity but how can I distribute the tables so that I can be sure that when I insert a row into table2, I can check to see if there is a matching row in table1 for table1_id?

Realistically, I expect that you need to reconsider your architecture.
It does not make sense to check for a matching row in table1 in a remote database while inserting data into table2 in a local database. The best case scenario would be that every insert into table2 would incur the overhead of a network round-trip plus the cost of querying the table in the remote database. If the network went down or if either of the two databases went down, the application would fail, which generally defeats the purpose of a distributed application. Plus, there would be all sorts of concurrency issues (i.e. I delete a row, but before I commit you query the row, see that it exists, and insert a child row. I commit, leaving your row orphaned).
Assuming you really need a distributed architecture, you would want to replicate table1 to both the local and remote nodes. You would then declare referential integrity constraints between your local copy of table1 and table2 (as well as between table1 and table2 on the remote database, assuming you want table2 data available there as well). Your replication process (preferrably using Streams but potentially using multi-master materialized views instead) would then have to be coded to deal with errors because of the asynchronous nature of replication (i.e. to notice that database1 deleted a parent row that you just inserted a child row for and resolve the conflict appropriately).
Justin

Maintaining referential integrity using MS SQL server

Some time ago I posted a question relating to the following extension:
<extension vendor-name="kodo" key="jdbc-delete-action" value="null"/>
Kodo generates a "on delete set null" constraint for this, however ms sql
server does not support this. Since I don't want to matain this referential
integrity in my java code (meaning as soon as an object is deleted, setting
all references to it to null), I tried to implement a custom dictionary with
the default ms sql server solution for this problem: creating a trigger by
overriding the "getAddForeignKeySQL" method. This works fine when creating a
database from scratch using the schema tool, however, when updating an
existing databasebase schema, this is ignored, thereby not solving the
problem of having the database maintenance automated. I suppose I have to
write code for checking whether the trigger already exists. Browsing through
the code, I couldn't figure out how this is done. Can someone give me
suggestions on how to do this (and if this takes a lot of effort).
I also would like to know whether solarmetric has intentions to deal with
this problem in their framework. To be honest, I was quite surprised that
Kodo doesnt take care of this, leaving my database in an inconsistent state.
kind regards,
Christiaan

"Abe White" <[email protected]> schreef in bericht
news:caaunu$ecj$[email protected]..
>
I also would like to know whether solarmetric has intentions to dealwith
this problem in their framework. To be honest, I was quite surprisedthat
Kodo doesnt take care of this, leaving my database in an inconsistentstate.
>
Well, I would say that you're the one leaving the database in an
inconsistent state by not keeping your object model consistent :)From the manual:
6.2.2.12. jdbc-delete-action
If a field holds a relation to another object, you can use the
jdbc-delete-action field extension to control the delete action of the
database foreign key that models this relation. Possible values are:
null: Null the column(s) of this foreign key when the related record is
deleted.
It does mean that if the primary key record is deleted, all foreign keys to
the record are set to null, right? Since the jdo framework is about database
independence, not writing sql code (and of course lots more;) and Kodo
supports ms sql server, I would have expected that kodo to set the foreign
key to null if the object is deleted. Even if I do know sql server supports
does not support a 'on delete set null' sql statement;)
>
We have no plans to create triggers at this time.
What do you mean when you say "it is ignored" when you're updating?
Exactly what tool are you running, what actions are you running with, is
the foreign key extension present, and what is the outcome?Like I said, I wrote code in the "getAddForeignKeySQL" in the dictionary, so
a trigger is created when creating the database in the workbench (by running
the schematool). However, if the table already exists, but not the trigger,
refreshing the database from the workbench does not call the
getAddForeignKeySql to add the trigger to the table.

DRI (declarative referential integrity) and speed improvements.

EDITED: See my second post--in my testing, the relevant consideration is whether the parent table has a compound primary key or a single primary key. If the parent has a simple primary key, and there is a trusted (checked) DRI relation
with the child, and a query requests only records from the child on an inner join with the parent, then sql server (correctly) skips performing the join (shown in the execution plan). However, if the parent has a compound primary key, then sql server
performs a useless join between parent and child. tested on sql 2008 r2 and denali. If anyone can get sql server NOT to perform the join with compound primary keys on the parent, let me know.
ORIGINAL POST: I'm not seeing the join behavior in the execution plan given in the link provided (namely that the optimizer does not bother performing a join to the parent tbl when a query needs information from the child side only AND
trusted DRI exists between the tables AND the columns are defined as not null). The foreign key relation "is trusted" by Sql server ("is not trusted" is false), but the plan always picks both tables for the join although only one is needed.
If anyone has comments on whether declarative ref integrity does produce speed improvements on certain joins, please post. thanks.
http://dinesql.blogspot.com/2011/04/does-referential-integrity-improve.html

I'm running sql denali ctp3 x64 and sql 2008 r2 x64, on windows 7 sp1. I've tested it on dozens of tables, and I defy anyone to provide a counter-example (you can create ANY parent table with two ints as a composite primary key, and then a child table using
that compound as a foreign key, and create a trusted dri link between them and use the above queries I posted)--any table with a compound foreign key relation as the basis for the DRI apparently does not benefit from referential integrity between those tables
(in terms of performance). Or to be more precise, the execution plan reveals that sql server performs a costly and unnecessary join in these cases, but not when the trusted DRI relation between them is a single primary key. If anyone has seen a different result,
please let me know, since it does influence my design decisions.
fwiw, a similar behavior is true of sql server's date correlation optimization: it doesn't work if the tables are joined by a composite key, only if they are a joined by a single column:
"There must be a single-column
foreign key relationship between the tables. "
So I speculate, knowing absolutely nothing, that there must be something deep in the bowels of the engine that doesn't optimize compound key relations as well as single column ones.
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[parent](
[pId1] [int] NOT NULL,
[pId2] [int] NOT NULL,
CONSTRAINT [PK_parent] PRIMARY KEY CLUSTERED
[pId1] ASC,
[pId2] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Children](
[cId] [int] IDENTITY(1,1) NOT NULL,
[pid1] [int] NOT NULL,
[pid2] [int] NOT NULL,
CONSTRAINT [PK_Children] PRIMARY KEY CLUSTERED
[cId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Children] WITH CHECK ADD CONSTRAINT [FK_Children_TO_parent] FOREIGN KEY([pid1], [pid2])
REFERENCES [dbo].[parent] ([pId1], [pId2])
ON UPDATE CASCADE
ON DELETE CASCADE
GO
/* the dri MUST be trusted to work, but it doesn't work anyway*/
ALTER TABLE [dbo].[Children] CHECK CONSTRAINT [FK_Children_TO_parent]
GO
/* Enter data in parent and children */
select c.cId FROM dbo.Children c INNER JOIN Parent p
ON p.pId1 = c.pId1 AND p.pId2 = c.pId2;
/* Execution plan will be blind to the trusted DRI--performs the join!*/

Maintaining referential integrity

Hi,
How do I ensure that referential integrity is maintained when deleting rows from a table that has a primary key referenced in another table by a foreign key? Is there a way when creating the table (or by altering the table) to include a check for child records and delete child records at the same time of deleting the parent record?
thanks

Hi,
are you thinking about a cascading delete?
If yes, you can create a foreing key like this:
ALTER TABLE my_table ADD CONSTRAINT my_fk FOREIGN KEY
REFERENCES my_master_table(my_pk_column)
ON DELETE CASCADE:
This is a foreing key which allows to delete a parent record for which child records exist.
The child records will be deleted automatically.
If you do not want the child records to get deleted you can also choose:
ALTER TABLE my_table ADD CONSTRAINT my_fk FOREIGN KEY
REFERENCES my_master_table(my_pk_column)
ON DELETE SET NULL;
This will update the foreign keys to NULL.
Hope this helps,
Lutz

Referential integrity based on a view

Hi,
I am having difficulty in trying to build referential integrity based on a view.
     I have explained below with an example:
     I have a table called 'vehicles' which is the master table.
     CREATE TABLE vehicles(
     type VARCHAR2(20),
     model_number NUMBER(5),
     price NUMBER(5),
     CONSTRAINT vehicles_pk PRIMARY KEY(type, model_number)
     INSERT INTO vehicles(type, model_number, price) VALUES ('CAR', 1, 100);
     INSERT INTO vehicles(type, model_number, price) VALUES ('BIKE', 1, 50);
     INSERT INTO vehicles(type, model_number, price) VALUES ('CAR', 5, 200);
     INSERT INTO vehicles(type, model_number, price) VALUES ('BIKE', 7, 50);
     I have a view called 'vu_cars' which lists only the CAR from the table 'vehicles'.
     CREATE VIEW vu_cars
     AS
     SELECT model_number
     FROM vehicles
     WHERE
          type = 'CAR';
     I have a table called 'car_properties' which contains the car properties and has referential integrity based on the view 'vu_cars'
-- This create statement throws an error, am I missing something ... ?
     CREATE TABLE car_properties(
     model_number VARCHAR2(20),
     number_of_doors NUMBER(5),
     PRIMARY KEY(model_number),
     CONSTRAINT vu_cars_fk FOREIGN KEY (model_number) REFERENCES vu_cars(model_number)
-- Actually I wanted to execute the below insert statements, but am stuck with the above create statement of the table car_properties. Is there anyway to resolve this ?
     --Below should be inserted correctly:
     INSERT INTO car_properties(model_number, number_of_doors) VALUES (1, 4);
     INSERT INTO car_properties(model_number, number_of_doors) VALUES (5, 2);
     --This should throw an error:
     INSERT INTO car_properties(model_number, number_of_doors) VALUES (7, 2);

One approach would be to:
1. Add a TYPE column to CAR_PROPERTIES.
2. Add a check constraint on the TYPE column in CAR_PROPERTIES that requires it to equal 'CAR'.
3. Create a foreign key constraint on CAR_PROPERTIES referencing both MODEL_NUMBER and TYPE in VEHICLES. This requires a primary or unique constraint on these two columns in VEHICLES, but you already have one. However, both columns should have the same data type in both tables.
It might look something like this:
SQL> CREATE TABLE vehicles(
2 type VARCHAR2(20),
3 model_number NUMBER(5),
4 price NUMBER(5),
5 CONSTRAINT vehicles_pk PRIMARY KEY(type, model_number)
6 );
Table created.
SQL> INSERT INTO vehicles(type, model_number, price) VALUES ('CAR', 1, 100);
1 row created.
SQL> INSERT INTO vehicles(type, model_number, price) VALUES ('BIKE', 1, 50);
1 row created.
SQL> INSERT INTO vehicles(type, model_number, price) VALUES ('CAR', 5, 200);
1 row created.
SQL> INSERT INTO vehicles(type, model_number, price) VALUES ('BIKE', 7, 50);
1 row created.
SQL> CREATE TABLE car_properties(
2 -- Note new column with both not null and check constraint
3 type VARCHAR2(20) not null check (type = 'CAR'),
4 -- Note change in data type to be the same as vehicles table
5 model_number NUMBER(5) not null,
6 number_of_doors NUMBER(5),
7 PRIMARY KEY(model_number),
8 -- Note new constraint referencing vehicles table
9 CONSTRAINT vehicles_fk FOREIGN KEY (type, model_number) REFERENCES vehicles(type, model_number)
10 );
Table created.
SQL> INSERT INTO car_properties(type, model_number, number_of_doors) VALUES ('CAR', 1, 4);
1 row created.
SQL> INSERT INTO car_properties(type, model_number, number_of_doors) VALUES ('CAR', 5, 2);
1 row created.
SQL> INSERT INTO car_properties(type, model_number, number_of_doors) VALUES ('BIKE', 7, 2);
INSERT INTO car_properties(type, model_number, number_of_doors) VALUES ('BIKE', 7, 2)
ERROR at line 1:
ORA-02290: check constraint (TEMP.SYS_C0095831) violated
SQL> INSERT INTO car_properties(type, model_number, number_of_doors) VALUES ('CAR', 7, 2);
INSERT INTO car_properties(type, model_number, number_of_doors) VALUES ('CAR', 7, 2)
ERROR at line 1:
ORA-02291: integrity constraint (TEMP.VEHICLES_FK) violated - parent key not
found
SQL> INSERT INTO car_properties(type, model_number, number_of_doors) VALUES (NULL, 1, 4);
INSERT INTO car_properties(type, model_number, number_of_doors) VALUES (NULL, 1, 4)
ERROR at line 1:
ORA-01400: cannot insert NULL into ("TEMP"."CAR_PROPERTIES"."TYPE")Defining a default value for the TYPE column in CAR_PROPERTIES (to set it to 'CAR') might make this approach a little less obtrusive.

What is meant by referential integrity

hi
what is meant by referential integrity

Hi,
Referential integrity is the property that guarantees that values from one column depend on values from another column. This property is enforced through integrity constraints.
If you set this flag a check for referential integrity is performed for this InfoObject, against the master data table or ODS object. The InfoObject is checked for valid characteristic values.
It is used when v r doing Flexi update...
Prerequisites for checking for referential integrity:
Data is updated flexibly
You have activated error handling in the BW scheduler (Tab page Update)
On the Update tab page in the BW scheduler, you have selected the option Always update data, even when no master data exists for the data.
send ur id, i will send u screen shot of ref.integrity
regards
reena

How to find the table name on which integrity constraint not found

Hi All
How to acheive this
I have a lot of tables with lot of primary key - foreign key
relationship.
In plsql
when any inserts happen in the child table & the corresponding row is not present in the parent table, we get an exception
ORA-02291: integrity constraint (user1.ppk) violated - parent key not found
On this exception , in the exception block i want to trap teh name of the parent table on which the primary key for the particular child table was not there
Is it possible to retrieve the parent table in this way. I am looking for a generic plsql code block which can help to acheive this
Regards

scott@ORA92> SET SERVEROUTPUT ON
scott@ORA92> DECLARE
2    e_no_parent_key EXCEPTION;
3    PRAGMA            EXCEPTION_INIT (e_no_parent_key, -2291);
4    v_fk_cons       VARCHAR2 (61);
5    v_owner            VARCHAR2 (30);
6    v_parent_table VARCHAR2 (61);
7    v_pk_cons       VARCHAR2 (30);
8    v_parent_column VARCHAR2 (30);
9 BEGIN
10    INSERT INTO emp (empno, deptno) VALUES (99, 60);
11 EXCEPTION
12    WHEN e_no_parent_key THEN
13       -- extract schema.constraint_name from sqlerrm:
14       v_fk_cons:= SUBSTR (SQLERRM,
15                     INSTR (SQLERRM, '(') + 1,
16                     INSTR (SQLERRM, ')') - (INSTR (SQLERRM, '(') + 1));
17       DBMS_OUTPUT.PUT_LINE ('Foreign key constraint violated: ' || v_fk_cons);
18       -- extract parent schema.table and parent key:
19       SELECT owner, table_name, constraint_name
20       INTO     v_owner, v_parent_table, v_pk_cons
21       FROM     user_constraints
22       WHERE     (owner, constraint_name) =
23           (SELECT r_owner, r_constraint_name
24            FROM     user_constraints
25            WHERE     owner || '.' || constraint_name = v_fk_cons);
26       DBMS_OUTPUT.PUT_LINE ('Parent table: ' || v_owner || '.' || v_parent_table);
27       DBMS_OUTPUT.PUT_LINE ('Parent key: ' || v_owner || '.' || v_pk_cons);
28       -- extract parent table columns:
29       FOR rec IN
30         (SELECT column_name
31          FROM   user_cons_columns
32          WHERE owner = v_owner
33          AND    table_name = v_parent_table
34          AND    constraint_name = v_pk_cons)
35       LOOP
36         DBMS_OUTPUT.PUT_LINE
37           ('Parent table column: ' || rec.column_name);
38       END LOOP;
39 END;
40 /
Foreign key constraint violated: SCOTT.FK_DEPTNO
Parent table: SCOTT.DEPT
Parent key: SCOTT.PK_DEPT
Parent table column: DEPTNO
PL/SQL procedure successfully completed.

SQL*Loader and integrity constraints

I am running into trouble with integrity constraints in my SQL*Loader script runs. Should I be going up to unix and removing the constraints from sqlplus, then asking the wizard to reinstall them after the data load? Is this documented somewhere? I can't find it. Sorry for asking such a basic question.
Thanks,
Ann Cantelow

Hi,
Your approach is correct.
Create tables first
Move data via the scripts
Create contraints, indexes, primary keys
See the User Guide for the ORacle Migration Workbench http://otn.oracle.com/tech/migration/workbench
Regards
John

Self Referential integrity constraint?

Similar Messages

Maybe you are looking for