Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Truncate Referenced Table Expand / Collapse
Author
Message
Posted Tuesday, January 6, 2009 4:16 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, July 17, 2014 6:57 AM
Points: 55, Visits: 159
Comments posted to this topic are about the item Truncate Referenced Table
Post #630429
Posted Monday, January 19, 2009 5:23 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, April 22, 2014 5:40 PM
Points: 209, Visits: 302
Is there any reason why you used NVARCHAR(128) rather than SYSNAME?

SYSNAME would make the script more portable between versions - and enforce restrictions on content.
Post #639574
Posted Monday, January 19, 2009 6:36 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 6:09 PM
Points: 36,782, Visits: 31,239
Tim.Wilson-Brown (1/19/2009)
Is there any reason why you used NVARCHAR(128) rather than SYSNAME?

SYSNAME would make the script more portable between versions - and enforce restrictions on content.


I agree that SYSNAME would be more appropriate, but SYSNAME is nothing more than a synonym for a NOT NULL NVARCHAR(128). From BOL...

sysname is a system-supplied user-defined data type that is functionally equivalent to nvarchar(128), except that it is not nullable. sysname is used to reference database object names.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #639588
Posted Monday, February 2, 2009 11:53 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, October 22, 2013 1:40 AM
Points: 26, Visits: 104
I got following error while compiling this x_TruncateTable proc:

Server: Msg 197, Level 15, State 1, Procedure x_TruncateTable, Line 126
EXECUTE cannot be used as a source when inserting into a table variable.

plz clarify on this.I am executing it on sql server 2000.

thx
Post #648596
Posted Tuesday, February 3, 2009 5:42 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 6:09 PM
Points: 36,782, Visits: 31,239
Sanjay (2/2/2009)
I got following error while compiling this x_TruncateTable proc:

Server: Msg 197, Level 15, State 1, Procedure x_TruncateTable, Line 126
EXECUTE cannot be used as a source when inserting into a table variable.

plz clarify on this.I am executing it on sql server 2000.

thx


A little bit of simple troubleshooting (double clicking on the error message) shows that this code was never designed to work in SQL Server 2000. You will need to change the @fk table variable and all of it's references to a Temp Table in order for this to work in SQL Server 2000.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #648743
Posted Tuesday, May 19, 2009 3:55 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, July 25, 2014 11:04 PM
Points: 126, Visits: 500
Like it well enough, was hopping for a SPROC that took into account dependencies across the entire database creating levels. With these levels you could say work from the branch inward. Truncating all children. then all parnet/children so on and so on until you arrived at an empty database with no keys.

On second thought I guess it would be even easier if I'm ending up with an empty db just to modify your sproc to only include the top loop that scripits out the FK to a "real" table and drops the original. Then call it with a sp_foreachtable statment.

Then truncate again using sp_foreachtable.

Than write another sproc that uses your stored FK's to recreate all the FK's because every table is empty i.e. null every constraint should create as it will validate true and you just nocked one out of the park...

I'll post my code when I finish.

Thanks,
T



Post #720194
Posted Tuesday, May 19, 2009 9:03 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, October 22, 2013 1:40 AM
Points: 26, Visits: 104
I have one more question, if two tables are refering each other how can we truncate both tables?
Post #720277
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse