March 28, 2013 at 9:22 am
good question. but for the life of me, i cannot come up with a reason to use this (nor anyone else where I work)- anybody?
jg
March 28, 2013 at 11:40 am
BOL - Restrictions
You cannot use TRUNCATE TABLE on tables that:
•Are referenced by a FOREIGN KEY constraint. (You can truncate a table that has a foreign key that references itself.)
Do we have any chance to use a table that has a foreign key that references itself?
--------------------------------------
;-)“Everything has beauty, but not everyone sees it.” ― Confucius
March 28, 2013 at 2:00 pm
Thank you for the posting.
We have many different ways to approach it. Is it a good idea or a bad idea?
--------------------------------------
;-)“Everything has beauty, but not everyone sees it.” ― Confucius
March 29, 2013 at 3:52 am
gmby (3/28/2013)
good question. but for the life of me, i cannot come up with a reason to use this (nor anyone else where I work)- anybody?jg
This scenario is often used for hierarchy. Stewart provided an example above.
--------------------------------------------------------------------------------------
Hai Ton
My Db4Breakfast blog.
March 29, 2013 at 10:00 am
Outside of a hierarchy example, I can't think of when you would have a table foreign key reference to itself.
March 29, 2013 at 7:07 pm
Thanks.
April 1, 2013 at 1:53 am
Nice one..
--
Dineshbabu
Desire to learn new things..
April 2, 2013 at 2:55 am
KWymore (3/29/2013)
Outside of a hierarchy example, I can't think of when you would have a table foreign key reference to itself.
A piece of machinery that is no longer available because it has been superseded by a different piece of machinery, something like
create table MachineryParts(
PartID int identity not null primary key,
PartDescription nvarchar(100) not null,
IsAvailable bit not null,
ReplacedByPartID int constraint fkMachineryPartsReplacement foreign key references MachineryParts
)
April 2, 2013 at 11:16 am
Strange situation, but informative.
Thanks for the question.
- webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
April 8, 2013 at 6:22 am
+1 🙂
Angad
--Angad Singh
If I Stop Learning, I Cease to Be A SIKH !
April 9, 2013 at 12:55 am
nice and straightforwad - instinct worked for me ..:w00t:;-)
~ demonfox
___________________________________________________________________
Wondering what I would do next , when I am done with this one :ermm:
April 22, 2013 at 1:55 am
I got it correct. However assuming some other logic but anyways got corrected by the explanation and got one point (to my bonus) 🙂
April 25, 2013 at 7:57 am
not really a frequent usage, but an interesting question
April 30, 2013 at 10:33 am
Good question but neither answer was correct. Granted you do NOT get an error but the truncate does not technically run either. If you go back and view the table data you will see that data has not been removed.
April 30, 2013 at 10:37 am
bgdjwoods (4/30/2013)
Good question but neither answer was correct. Granted you do NOT get an error but the truncate does not technically run either. If you go back and view the table data you will see that data has not been removed.
Don't know what you are doing, but I added a couple of selects and it sure looks like the data is gone to me:
CREATE TABLE dbo.Test
(
Col_1 INT PRIMARY KEY
,Col_2 INT REFERENCES Test(Col_1)
,Col_3 INT IDENTITY
)
;
INSERT INTO dbo.Test VALUES (1,1);
INSERT INTO dbo.Test VALUES (2,2);
INSERT INTO dbo.Test VALUES (3,3);
GO
select * from dbo.Test;
go
TRUNCATE TABLE Test;
GO
select * from dbo.Test;
go
drop table dbo.Test;
go
Viewing 15 posts - 16 through 30 (of 32 total)
You must be logged in to reply to this topic. Login to reply