April 12, 2005 at 12:17 pm
For once, I'm glad I'm wrong too!
-Isaiah
April 12, 2005 at 12:20 pm
Believe me I've had that feeling too
* Noel
April 13, 2005 at 10:01 am
-- Create a trigger on YourTable with the following code:
Create Trigger [YourTableInsertTrigger] on [YourTable] Instead of Insert
As
Truncate Table dbo.[YourTable]
Insert dbo.[YourTable] Select * from Inserted
-- Execute this in your script or procedure:
Insert YourTable
Select * from YourTable Where <criteria of rows you want to keep>
April 13, 2005 at 2:53 pm
That's a nice try but:
... Too many problems
* Noel
April 13, 2005 at 4:16 pm
I'm just not feeling the luv...
April 13, 2005 at 9:22 pm
Elaine wrote: " Part of the problem is that we ran out of disk space, so I don't have enough room to save to another table the data I need to keep"
Elaine, run the following command to reduce the size of the logged transactions, then shrink the database...
BACKUP LOG database_name WITH TRUNCATE_ONLY
... that should free up some space...
I don't normally recommend shrinking the database but this is an exceptional case.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 14, 2005 at 2:47 am
The 'dangerous' part about using EM for changes, is that you have no explicit transaction control. If you click the wrong button - oops - no other choice than to take the system offline and start digging for the latest good backup.. (and perhaps also start thinking of a good explanation to the PHB)
In QA you can do:
BEGIN TRAN
<do some SQL>
..if all went as expected, COMMIT
..if something funky happened, ROLLBACK
..after that, you're back to square on (boss and users hopefully unaware) and you can figure out what went wrong and how to fix it.
/Kenneth
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply