Hello and thanks for both the compliment and the input. I certainly do agree that options are good to have and do appreciate your technique. In the projects that I have done with 60 - 180 million rows per table and plenty of read/write activity all throughout the day, the Triggers did not pose a problem for performance; the UPDATE and DELETE operations were JOINed on the Clustered Index (PK in these cases) and was rather quick.

Since we are only working on one table at a time here (or at least no related tables), there is no concern regarding referential integrity or object relationships. In the case that the table being restructured is a child table where both it and the original table have cascade delete FKs pointing to the same parent table, if a record is deleted from the parent it will delete in both child tables leaving the trigger with no matching rows for the DELETE operation, but no logical harm. In the case that the table being copied is a parent table and both it and the original have a cascade delete FK to the same child table, if the parent gets a DELETE it will cascade to the child table and the trigger will replicate the DELETE to the copy table which will then try to cascade the delete to the child table but there will be no matching row(s) now, but again no logical harm. If the situation is more complex then the FKs can always be added during the release, just before swapping the tables.

Take care,

Solomon...