So you have two versions of a database sitting around – maybe you’ve been trying things out on your development box, and now you want to move it all over to production. If it’s just a new table here and an extra column there, you could do it by hand, but if you’ve made lots of changes, it would be nice to let the computer do it for you.
Enter MySQL Workbenchmysqldiff.
Excellent guide, I got here from the mysql forums.
I haven’t managed to go through your other posts, and I apologize if this is not the right place to ask further: how would you handle Data migration from the older database to the new? (Can MySQL Workbench be of any help? What would be the approach that automates most of this task?)
Any advice would be appreciated.
ana
Do you know of any way to get around the “same name” restriction for generating an alter script? We store our generation scripts without db names, relying on a ‘use db’ statement before executing the script. However, the only way we can generate an alter script for new changes is through a 10 step (or so) process of reverse engineering the old one, exporting it with a given db name, then recreating it with the same name.
ana: Is there really much migration you have to do? Can you not just alter the db in place? Failing that, the old Migration Toolkit is still available in the archives, and can handle data migration between MySQL servers. Eventually that functionality will probably be added to the new Workbench.
Bart: echo 'use dbName;' | cat - script.sql > scriptForWorkbench.sql, perhaps?
Yes the same database name is very annyoning anybody know a solution?
[…] ??????????? Make an ALTER TABLE script with MySQL Workbench « A Little Noise […]
I know this is an OLD post, but since the steps are not outlined and on the video – and the video is gone – can anyone help with the steps? This seems to be something we all need to do yet very few how-to posts.
Leave a Reply