So there is no actual constraint created from this.... ok, got it. I was assuming that I couldn't drop this table because I had this 'parlance' (that must be french for limitation). When I try to drop the table the error is 'This table is referenced by a Foreign Key'. Which I now found which column has a foreign key referenced against it, but don't know what table is referencing it (how do I find this?).
What I have is a multi level problem. I can't drop the table because there's a foreign key, of which I have no idea which table is linked. Secondly, I cannot just go and ALTER the table because there's another table in the DB that contains a column name that I want to use in this table. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On > Behalf Of Bill Downall > Sent: Thursday, December 06, 2001 12:12 PM > To: [EMAIL PROTECTED] > Subject: RE: Duplicate Column Names = Foreign Key... UGH > > On Thu, 6 Dec 2001 11:23:35 -0600, Eric Peterson wrote: > > >Why must tables who have the same column names have exact data > >types? Isn't it creating a foreign key relationship between the two? > > No, that's not a Foreign Key. In database parlance, that's more like a > "domain," an assumption that R:Base makes that if you are naming > things identically, they should contain data that is similarly defined. > R:Base's data type restriction on identically named columns is not part > of the SQL standard, but is an extension beyond that standard. > > Foreign Keys in R:Base, however, conform exactly to the ANSI > standard SQL. A Foreign Key is an explicit relationship between the > DATA in columns in two tables. The twol columns should always have > the same datatype, but they do not need to have the same name. The > value in a Foreign Key column must match a value in a column in a > table that has a defined Primary Key or Unique Key. The Foreign Key > is usually the "many side" of a "one-to-many" releationship. You can > choose whether you want to allow it to ever be null, but if it is not null > if > must always have a match in the related primary key column of the > referenced table. > > With your identical column names example, there is no enforcement at > all for matching values, just a matching data type. > > Bill > > > > ================================================ > TO SEE MESSAGE POSTING GUIDELINES: > Send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: INTRO rbase-l > ================================================ > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l
