删除和添加列时纠正错误处理

Question

I have a table that is currently using a couple of columns named DateFrom and DateTo . I'm trying to replace them with a single NewDate column, populated for existing rows with the value from DateFrom .

I need good error/transaction handling as, if the change fails, I don't want a halfway in-between table, I want to revert.

I've tried a number of things but can't get it to work properly. Any help is appreciated as I'm far from experienced with this.

I started with

BEGIN TRAN

ALTER TABLE TableName
ADD NewDate DATETIME

IF @@ERROR = 0 AND @@TRANCOUNT = 1
UPDATE TableName
SET NewDate = ValidFrom
....

This fails immediately as NewDate is not currently a column in the table. Fine, so I add a GO in there. This breaks it into two batches and it now runs, except it makes the @@ERROR check pointless. I also can't use a local variable as those are lost after GO as well. Ideally I'd like to use a TRY...CATCH to avoid checking errors after each statement but I can't use a GO with that as it needs to be one batch.

None of the articles I've found talk about this situation (error handling with GO ). So the question is: Is there any way I can get the transaction-with-error-handling approach I'm looking for when adding and updating a column (which seems to necessitate a GO somewhere)?

Or am I going to have to settle for doing it in several batches, without the ability to roll back to my original table if anything goes wrong?

Answer 1

Why are you worried about creating the new column in the transaction? Just create the column and then populate it. You don't even need an explicit tran when populating it. If it fails (which is very unlikely), just do the update again.

I would do the following steps

1. Add new column
2. Update new column
3. Check to see if the data in the new column looks correct
4. Drop the old columns no longer needed (you may want to check where these columns are being used before dropping them eg are they used in any stored procedures, reports, front-end application code)

Also, it is worth adding more context to your question. I assume you are testing a script against a test database and will later apply the script to a prod database. Is the prod database very big? Very busy? Mission critical? Backed up on a schedule?