A few weeks after the first version of dbForge Schema Compare for SQL Server had been released we received a letter from one of our users who was testing our product to find out if it’s capable to support his DBA tasks. Here is the excerpt from his letter:
Nowadays I work as ERP-system (industry enterprise management system) adoption consultant. Though this ERP-system was originally developed for Microsoft SQL Server 2000 platform but it allows deployment on SQL Server 2005. Second decision has better performance characteristics, but at the same time architectural differences between SQL Server version 2000 and 2005 impede installation of patches and regular database maintenance operations.
The only way out of this situation is this:
- periodically downgrade database from SQL Server 2005 to 2000
- perform maintenance operations over database on SQL Server 2000 platform
- upgrade database back to SQL Server 2005
But this decision makes difficulties…
Large database – big problems
Oh yes, it does! This customer kindly offered us a demo-database of this ERP-system, which contained over 6,600 objects. So we began testing dbForge Schema Compare on this base … and we got stuck with it.
After hitting several bugs and performance problems we finally managed to synchronize this huge database with an empty one. Hurrah! The synchronization script generated by dbForge Schema Compare was up to 90 MBytes.
We released a new build with fixes which made dbForge Schema Compare much stronger against large databases.
And what are the competitors?
We have tested several recent versions of schema comparison products-competitors on this database – no one of them has managed to synchronize it.
In the next posts I’ll give you some tips on how successfully synchronize large databases. See you soon!
[…] my previous post Schema Comparison Stress Testing I mentioned problems we met testing dbForge Schema Compare for SQL Server on large database. In […]