Comments
1 comment
-
There isn't a great solution, and we don't really automate this.
I'd do what you listed above, but I'd also think about repeating this. You ought to have a script that fixes these views after a restore. In SQL Clone or RG Clone, we'd link a script to the creation of the test database image, but as a general rule, your process should be scripted as follows:- backup ProdA
- backup ProdB (these can be in parallel)
- restore TestB (from ProdA backup)
- restore TestB (from ProdB backup)
- run CREATE OR ALTER VIEW on TestB to fix all references
- run CREATE OR ALTER VIEW on TestA to fix all references.
You could use SQL Compare once you've done this once to save a project that looks at your specific views (or all views) and then writes to a scripts folder. You could then compare this folder on disk to the restored db, but if you added/changed views, this wouldn't work.
My long term suggestion is to move to synonyms for each object and have all code reference these. Then when you restore, you still need steps 5/6 above, but you are only changing synonyms, which is less maintenance as multiple views/procs/etc could reference one synonym.
Add comment
Please sign in to leave a comment.
These 2 production databases get backed up and restored as 2 testing databases. (TestA, TestB)
The result is that the views in the test databases still point to the other production database.
(TestA <-> ProdB, ProdA <-> TestB)
I need to update the views in the test databases to point to each other. Right now, I can accomplish it via this method in SSMS...
...and repeat for the other database.
Is there a way to automate this with the Red Gate tools? I currently have the Toolbelt Essentials.
Thanks!