Tom, I would disagree in some circumstances. But one does need to minimize = them at all cost. I prefer a before insert/update trigger that does the = same thing, but that too can become a problem. Dick Goulet Senior Oracle DBA Oracle Certified 8i DBA -----Original Message----- From: Mercadante, Thomas F [mailto:thomas.mercadante@xxxxxxxxxxxxxxxxx] Sent: Tuesday, August 24, 2004 7:49 AM To: 'oracle-l@xxxxxxxxxxxxx' Subject: RE: Re[2]: What Sort of Privilege? Peter, I totally agree with you. Allowing Fk references from outside of the = schema is inviting confusion, duplication and disaster. There is really no = good reason for it. Tom Mercadante Oracle Certified Professional -----Original Message----- From: Peter Robson [mailto:pgro@xxxxxxxxx]=20 Sent: Tuesday, August 24, 2004 4:57 AM To: Jackie Brock Cc: oracle-l@xxxxxxxxxxxxx Subject: Re[2]: What Sort of Privilege? Whoa there everybody! While the answer is quite correct, of course (I read the FM years ago), = what has not been raised is the danger of allowing reference to multiply unhindered across numerous schemas. Be very careful if you choose to do this, otherwise, without a little = care, you may manage to lock your entire database solid with conflicting FKs! We did, learned our lesson, and now reference is ONLY permitted within = the one corporate schema. peter edinburgh ............. JB> references JB> All, JB> what kind of privilege new for creating a FK constraint which=20 JB> reference table belongs to another schema. JB> ALTER TABLE PAM.table1 JB> ADD CONSTRAINT FKCONS1 JB> FOREIGN KEY (ID) JB> REFERENCES schema1.table2 (ID2); JB> I have grant select,insert,update,delete for table2 BUT still I get=20 JB> insufficient privilege. any idea? JB> Hamid Alavi --=20 mailto:pgro@xxxxxxxxx ********************************************************************* This e-mail message, and any files transmitted with it, are confidential and intended solely for the use of the addressee. If = this message was not addressed to you, you have received it in error and any copying, distribution or other use of any part of it is strictly prohibited. Any views or opinions presented are solely those of the = sender and do not necessarily represent those of the British Geological = Survey. The security of e-mail communication cannot be guaranteed and the BGS accepts no liability for claims arising as a result of the use of this medium to transmit messages from or to the BGS. . http://www.bgs.ac.uk ********************************************************************* ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------