I have an oracle db which has no Foreign Keys, all table relations are handled by the software. For example, table Customer with columns Customer.customercode, Customer.Name where customercode is the primary key and table Order with columns Order.ordercode (PK), Order.customercode where customercode has no foreign key constraint. So far the application handles all transactions and takes care of all the table relations so that the data are consistent. I need to change this to a proper relational DB implementation, so I need to modify Order.customercode to be a FK from table Customer. Any sqlplus statement to do this without losing my data?
In Oracle, creating a foreign key would never lose any data, but it will fail if the data doesn't correspond to the new constraint. Assuming your data is OK, you can use an alter table statement:
ALTER TABLE order
ADD CONSTRAINT order_customer_fk FOREIGN KEY (customercode)
REFERENCES customer(customercode)
Related
I came across this T-SQL code in a client's database today:
CREATE TABLE dbo.Dates
(
MarketDate date,
PRIMARY KEY (MarketDate),
FOREIGN KEY (MarketDate) REFERENCES dbo.Dates (MarketDate)
)
It is unclear to me what purpose can be served by allowing the primary key column to have a foreign key relationship back to itself. Naturally I have deleted the relationship.
Would this foreign key have any effect at all? Is there ever a use case which would justify using it? If not then why would SQL Server permit such a relationship.
The only reason I can imagine is that the creator of the table wanted to disallow the use of TRUNCATE TABLE statements against the Dates table.
I have not done much database design work and I was searching around for some example.
While I know the difference from a primary and foreign key, one thing that caught be off guard was that even if a Table has a primary key and is used as a foreign key in another table, as I was used the GUI SSMS tools, I noticed that I sometime end up having this
PhoneID (PK, int, not null)
While my User table
UserId(PK,FK, int, not null)
BOTH of these tables have these ID's as primary keys in those tables, along with foreign keys in other tables, but why does one of them have "PK,FK" obviously I accidentally created it, but should it be like that?
It is Possible for a Primary key to be a Foreign Key as well at the same time.
But looking at you database design, In your case I dont think it was intentional it was done by mistake. And if it wasnt done by mistake then you need to fix it.
In your dbo.PhoneType Table the column PhoneTypeID needs to be a Primary key only not a Foreign key. My guess is this was done by mistake, you wanted to create a Foreign key in your dbo.Phone table on column PhoneTypeID referencing PhoneTypeID column in dbo.PhoneType table. But somehow you end up create a foreign key constraint on the Primary key column of the dbo.Phontype table.
This Design contradicts constraints.
In simple english : The foreign Key Constraint on your dbo.PhoneType(PhoneTypeID) enforces that you cannot have a PhoneTypeID in dbo.PhoneType table unless it exists in PhoneTypeID column of dbo.Phone table.
On the other hand Foreign Key Constraint on dbo.Phone(PhoneTypeID) enforces that you cannot have a PhoneTypeID in dbo.Phone unless it exists in dbo.PhoneType(PhoneTypeID).
and same is true for the UserID column in dbo.Users table.
Solution
You need to drop the following Constraints to make it work properly.
1) In dbo.PhoneType table Drop Foreign key constraint referencing
PhoneTypeID column in dbo.phone table.
2) In dbo.Users Table drop the Drop Foreign key constraint referencing
UserID column in dbo.phone table.
It's entirely possible, yes. A primary key of a table could also be a foreign key referencing another table.
In your case, I'm not exactly sure what you did. You can check the constraints to see which column the UserId column is referencing.
As an additional note, simply adding a foreign reference to a table does not implicitly make that column a foreign key on another table. For example, just because you add FK_PhoneTypeID to the Phone table, SQL Server does not automatically make PhoneTypeID column in the PhoneType table a FK. In your statements, somewhere, it's possible that you made assignments to other columns, or even to themselves.
I have set up my tables like so:
Table A:
Id
[...]
Table B:
Id
AId
[...]
I have a foreign key created as
FK_TableB_TableA where primary key table is Table A and its primary key is Id and the foreign key table is TableB and its foreign key is AId...
However, when I update my dbml for linq TableB is defined as an entityref instead of an entityset...
Adding a foreign key should generate a one-to-many relationship correct?
This is very generic but if I need to add more detail please let me know!
Didn't figure out why this was happening however on the dbml there was no association created between the two tables for whatever reason - therefore I just added the association.
I know that a a temporary table will only exist for as long as a session of SQL Server is open, but why can't you have foreign key restraints on them?
Imagine this scenario: You create a foreign key relationship from your temp table to a concrete table's key. One of the restrictions on a foreign key relationship is that you cannot delete a row from a key table that is depended upon by your temp table. Now, generally when you create foreign key relationships you know to delete the dependent table rows before deleting the related rows in the key table, but how does a stored procedure or any other call into the database know to delete rows from your temp table? Not only is it impossible to discover spurious foreign key dependencies, other sessions could not reach your temp table even if it could discover the relationship. This leads to spurious failures in delete statements as foreign key constraints restrict the key table for dependent rows.
You can create foreign keys between tables in tempdb. For example, try this:
use tempdb
create table parent
(
parent_key int primary key clustered
)
create table child
(
child_key int primary key clustered,
child_parent_key int
)
alter table child add constraint fk_child_parent foreign key (child_parent_key) references parent(parent_key)
insert into parent(parent_key) select 1
insert into child(child_key, child_parent_key) select 1, 1
insert into child(child_key, child_parent_key) select 2, 2 -- this fails because of the FK constraint
drop table child
drop table parent
Could be because you can't have cross-database foreign key constraints and temp tables technically are created in the TempDB database.
Unless you mean between a temp table and another temp table... but really there's lots of issues you get into when you talk about those kind of constraints on a temp table.
Why should not violate foreign key while enable in SQL Server?
We have two tables, Order Header and Order Detail.
Order header table's OrderID column references OrderDetail table's OrderID column.
Then I'm going to migrate with some data from production database to these table.
I just disable these table foreign key constraint and inserted data from production Db.
After insertion of data, the order details table's OrderID column contains the values 101,102,103, but the order header table's Order ID column contains value 100 only.
Then I try to enable the foreign key constraint using the following t-sql code
exec sp_msforeachtable "ALTER TABLE ? CHECK CONSTRAINT ALL"
Why should not violate the foreign key with existing data while enabling?
When you moving data from multiple tables which connected with FKey - you should:
or preserve key values in both tables
or issue new values changing appropriate FKey column in referencing table when moving
When you enabling the FKey constraint - it is by default checks for data consistency