Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Delete all but top 100 rows
Message
 
General information
Forum:
Microsoft SQL Server
Category:
SQL syntax
Environment versions
SQL Server:
SQL Server 2008
Application:
Web
Miscellaneous
Thread ID:
01600029
Message ID:
01600069
Views:
51
>>>>>
>>>>>Truncate?
>>>>
>>>>http://msdn.microsoft.com/en-us/library/ms177570.aspx
>>>
>>>Naomi, you make great contributions up here, really you do. But here's the difference between where you are and where I know you could be - the ability to answer this kind of question off the top of your head, even if someone wakes you up in the middle of the night. You know and I know that you are capable enough to answer this kind of question in your own words without just posting a link.
>>>
>>>Mike, a TRUNCATE is like a quick kill-shot to a table. Unlike a DELETE command that fires across all rows (which would fire any DELETE trigger and which also gets logged to the txaction log), a TRUNCATE by-passes all of that and gives the space occupied by the table "back" to the operating system.
>>>
>>>So a DELETE of all rows in a 10 billion row table means you can grab some coffee (or if you're JB...a six-pack of Blue Moon) - but a TRUNCATE of the same size table will likely occur in roughly a second or less.
>>>
>>>(More or less, the functional equivalent in VFP...I believe... is ZAP)
>>>
>>>And as little editorial...I've tricked people before with a trick question....if you put a TRUNCATE inside a SQL transaction, can you roll it back? Contrary to popular belief, the answer is yes. Because while SQL Server isn't logging individual rows, it IS logging the space being given back to the operating system - and therefore will attempt to give it back.
>>>
>>>Now...isn't that much better than a link? If nothing else, you've learned about my BFF's drinking abilities :)
>>
>>Well, if you want a better link you may want to read this article
>>
>>http://social.technet.microsoft.com/wiki/contents/articles/24130.miss-understanding-of-truncate-command.aspx
>>
>>I was not sure what was the reason for Mike's question - was it because he didn't know the command? And BTW, BOL reference is always a good answer - if there are extra questions after reading that link, then I can clarify them. Unlike .NET help which I often find very short and hard to get the right information, BOL offers comprehensive answer with good examples.
>
>Mike's mistake was he misunderstood the question. For some reason I thought we were talking about a real, permanent table. That was not in fact the case. I apologize for the mistake and for sowing confusion.
>
>I do know what a Truncate command does. That's why I reacted with surprise.

I think Nick was talking about the real table he wanted to clean up. If the table is big, then the usual advice is to select only rows we want to keep, truncate the table (zap in VFP) and put that saved rows back into original table. Of course, the process needs to be put in transaction.
If it's not broken, fix it until it is.


My Blog
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform