Databases are rarely isolated – and of course you should never allow development in your live production DB. So copies from backups or migrations are made, to provide safe dev environments for programmers to work in. Then they copy/migrate the new objects and scripts plus perhaps even data from their dev into your production DB (hopefully deployed via a staging DB too). That’s where it gets sticky.
How do they track which objects and scripts have been successfully transferred?
That’s where DB comparison tools come in. We’ve tried a lot over the years – RedGate’s SQL Compare, ApexSQL’s SQL Diff, DevArt’s dbForge, EMS’s SQL Manager and TulsaSoft’s SQL and Schema Examiner. Visual Studio Professional also has a schema compare. We’re pretty set on our current one and licence it to do a lot of work for us and our clients – so you benefit from controlled deployment and reality checks on the state of your live production data objects and code.
Basically, we can automatically transfer all your database tables, views, stored procedures and all their associated properties into our own database (on Azure SQL DB, Managed Instance, on-premises server etc) and follow that up with data. We can then work to develop and transfer back to your staging or production database. Even better, automatic highlighting flags up anything which has not been transferred properly.
A bonus is that our database copy is effectively a latest build and when we need to transfer anything to you, or simply check, we can see any unexpected changes your team has made to your production database since our transfer. Often, that is revealing and helps to bypass “on-the-fly” change issues.
When you need a reality check on your databases, let us know!
