>That's a good idea and I was thinking about the same approach too, but it doesn't answer the original question.

No, of course not, but I often try to suggest alternate ways of doing things, and I think this is appropriate in this case. Of course, it might require a redesign of the update procedures, but I think it is worth it, since it solves several problems all at once, including:

Test first, then update the database structure on the production database or client site(s), using a generic DB updating procedure that covers virtually all cases (!). This is the main reason I created this procedure in the first place.

Do this update unattended (late at night, when no user is using the DB).

Reconstruct corrupt indices.

Disable several updates while updating the DB structure - this may include audit trail, referential integrity, and others.

Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)