Over the years, our SQL Remote setup has experienced several schema changes. Now there are some (empty) tables that aren't in use anymore (since a few years already). Note that they are not referenced by other tables. So far, I have left them in the publications since they do not disturb and since dropping a table from a publication looks dangerously. However, I'd try to achieve this now as part of another schema change. Preconditions:
As such I can guarantee no site is using these obsolete tables anymore. However, they are still referenced inside procedures, triggers and the like. After studying some newsgroup threads, the important parts seems to be:
Question: Do these steps and their order make sense, or do I have overseen something of importance? (Of course these steps are going to be tested, tested, tested before production usage.) asked 23 Jun '10, 11:51 Volker Barth |
Your plan sounds good Volker, particularly the part at the end where you say that the steps and going to be tested (three times). Two comments :
Reg answered 25 Jun '10, 13:21 Reg Domaratzki Sounds like SQL Remote schema changes and paranoia form a nice pair:) - Thanks for your comments, partiucularly the 2nd one. I have planned to run the 2nd step against both consolidated and remotes (and in my particular case this should work) but I see that the general (and more paranoid) approach would be to delay these actions for the consolidated until step 4. - Or to split it up: E.g. code with inserts/updates in the obsolete tables might be already removed in step 2 whereas code with FK checks or the like might have to be retained until step 4. (As you see, I'm just "brain-storming") |