distal-attribute
distal-attribute
distal-attribute
distal-attribute

Table compare

User, date Message
Written by Rvanlaak
3 years ago
Category: Feature discussion
25 posts since Sat, 25 Dec 10
A great feature about HeidiSQL is that multiple servers / databases can easily be accessed from the tree on the left.

I use this to maintain three 'identical structured' environments:
- development environment (DEV)
- quality assurance / test environment (PQA)
- live environment (LIVE)

The only difference between the environments is the data that the tables contain.

Often, I made changes in the dev environment without documenting it in the conversion script. In that way I afterwards have to search which changes I made.

In my opinion a great HeidiSQL would be a 'table-structure-compare', that searches for changes between two tables, or more, maybe even between two entire databases.

The step after this compare feature would be a button to generate a update script ;-)
Written by ansgar
3 years ago
4801 posts since Fri, 07 Apr 06
That's a complex feature you are asking for. You know there are diff tools which can compare text files, e.g. your SQL dump from dev with the one from live. Beyond Compare is excellent for this task, I already used it to compare .sql files. However, that's surely a work around. You should probably starr issue #1289.
Written by Rvanlaak
3 years ago
25 posts since Sat, 25 Dec 10
Thanks for the Google Code issuewinkIt doesn't seem that active, but it indeed is mentioned before
Written by kalvaro
3 years ago
564 posts since Thu, 29 Nov 07
Certainly, the feature must be really difficult to get right: I've evaluated many database compare tools and they all suck (no exceptions).

The compare part is easy anyway: you just need to get normalized SQL dumps of both databases (mysqldump or even HeidiSQL should be enough) and compare them with your favourite file compare tool (I use WinMerge but there're many to choose from).
Written by ansgar
3 years ago
4801 posts since Fri, 07 Apr 06
What HeidiSQL supports currently is doing a SQL export directly onto another server. Doing that, you can tell HeidiSQL to drop tables before recreating them - probably that helps a bit. Of course this ends up in a full sync, not some incremental sync.
Written by brazil
3 years ago
16 posts since Thu, 27 Jan 11
Dropping tables in the production database to import development data seems not to be a very good idea to me.

I also work w/ different databases of equal structure (1 dev. and a few prod. DBs). Copying the ALTER TABLE statements from Heidi's SQL log into a changelog (w/ short comments) is not that hard.
"Copy line to new query tab" (context menu @ SQL log) is a neat feature: after doing so, just use another DB and alter it's table(s), too.
Written by Rvanlaak
3 years ago
25 posts since Sat, 25 Dec 10
Just because of that great feature that creates CREATE TABLE statements, in my opinion it would be great to add a simple comparisson feature.

It is even possible to select the fields of the selected table, and compare it with a field with the same fieldname of the other table. Don't you all think?
Written by brazil
3 years ago
16 posts since Thu, 27 Jan 11
possible: yes
quick hack: no
needful: NO
Written by kalvaro
3 years ago
564 posts since Thu, 29 Nov 07
I insist: comparing databases is quite trivial. As I explained, you can already compare two databases with HeidiSQL and a regular file compare tool.

The difficult part is creating the appropriate SQL statements to port changes. That's the key feature: without it, you need to duplicate manually any change you've detected. And no tool I'm aware of does it right, so I doubt HeidiSQL will succeed where everyone else fails (no offense, Anse). By adding half cooked features you can't rely on we won't have a better tool.
Written by djn
3 years ago
15 posts since Wed, 19 Sep 07
May I suggest a halfway solution that seems (at least to me) somewhat simpler to implement?

The idea would be for HeidiSQL to keep track of all DDL statements (CREATE, DROP, ALTER and such) since connection start, separated per database, and have them displayed/exported on request - either as a SQL file or copy-pastable text in a query tab.

This would allow to easily replicate on a deployed server any modification that has been tested and found working on a test server first (which is more or less the way a lot of people develops web applications - playing first on a localhost copy of the app and porting things over to the "real" one once it seems safe and sound).
Written by Rvanlaak
3 years ago
25 posts since Sat, 25 Dec 10
That sounds like a good intermediate sollution, but the problem with that is that it only works if only one developper is working with that database ;-)

Doesn't it sound like a great plan to make a start at comparing field-types within tables? After that, the complete comparrison features will automatically follow
Written by lemon_juice
3 years ago
128 posts since Tue, 29 Jun 10
Synchronizing table structure seems quite a difficult task and I don't know if it's possible to make it reliable in all cases. Sometimes the changes are obvious - like a new column is added or deleted. But what if a column is renamed? How would a program know that the developer really renamed the column? Maybe he deleted the old column and created a new one with the new name? This leads to critically different ALTER TABLE statements. The same could apply to renaming tables, indexes and foreign keys. Without tracking what the user does there would need to be some manual intervention in the process.

A pretty easy solution that would be handy would be an option to select objects (databases, tables, etc.) for comparison and heidi would make CREATE statements for these objects and send them to an external diff tool like TortoiseDiff or some other user-defined tool. This should be easy to do and would provide an easy way to compare structures.
Written by Rvanlaak
3 years ago
25 posts since Sat, 25 Dec 10
I think the goal isn't the synchronising, the goal should be a function that shows you where the differences are. Thereafter, the user has to alter the tables itself.

Selecting the objects yourself (as lemon_juice mentions) indeed is a good option
Written by Rvanlaak
3 years ago
25 posts since Sat, 25 Dec 10
I see a synchronize function has been made. Does it fit to the requirements as described in this issue? In that case that should be really great, and I want to thank the devvers for that
Written by ansgar
3 years ago
4801 posts since Fri, 07 Apr 06
Please stick to issue #1289 so we're not spreading discussions all over the internet.
 

Please login to leave a reply, or register at first.