After analyzing our users’ feedback on the first release of dbForge Schema Compare for SQL Server. We decided to change our roadmap for this product and to release version 1.1 of the product before adding new major features.
So what new features will this version include?
dbForge Studio for MySQL has the Database Designer functionality that allows you to build and view the structure of your database using the diagrams. You can read more about it in Getting Started with Database Designer article.
Database Designer also can save a database diagram as an image.
Saving Database Diagram as an image
To save database diagram as an image, perform the following steps:
If you often need to create and modify views in your MySQL development you will like dbForge Studio for MySQL in-place query editing feature. This feature allows integration of powerful Query Builder tool with view editor without annoying copy/paste.
In my previous post Schema Comparison Stress Testing I mentioned problems we met testing dbForge Schema Compare for SQL Server on large database. In this post I would like to give you some tips on processing large synchronization scripts.
Suppose you have compared two databases and want to synchronize them. You tried to generate the synchronization script but it’s about 100 Mb and simply couldn’t be stored in the memory. When you open it in SQL editor for execution, the application fails with ‘Out Of Memory’ error.
There are two solutions for this problem:
Recently we received a letter from our customer who was unsatisfied with the amount of Internet traffic that dbForge Studio for MySQL produced when he was working with the remote MySQL server via VPN connection.
Here are two tips on how you can reduce your traffic in dbForge Studio for MySQL, v3.50:
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…