Make Heidi more code-firendly

Having used many SQL engines around, I find it very strange that most (if not all) MySQL GUIs out there, including Heidi, makes writing SQL scripts a somewhat odd experience. Let me try to explain that...

For example, after connecting to MySQL with Heidi, there is a second tab called Query, where there is a very small portion of the screen where you can write some SQL. There is an empty area for result sets that takes almost all of my screen even if I don't run anything. (Yes, I know you can resize it, but let me continue...)

While you can open or save a SQL script, you do it by right clicking the editor instead of an usual File > Open, File > Save. If you want to open two files, you need first to create a new query tab, then right click that window to open the second file.

When I work with any SQL engine, 90% of my time spent on it is actually writing or running SQL, so the GUI should make it a little bit comfortable to run SQL on SQL databases.

I really don't mean code completion or other fancy stuff. It is just some basic text editor flow that is missing. Some small changes to the UI could really improve that, making it more comfortable to write SQL and work with multiple SQL scripts.

So, here are my suggestions to make this tool more code-friendly:

* Move file management stuff to File menu, like New, Open, Save, Save As... instead or right click
* With that, File > New or Open should create the new tab for the file (unless the tab is new and empty)
* Make the SQL editor area use the full tab by default
* Hide the result area until you actually run a query, similar to how MS Management Studio does

These are more related to maintaining the focus when working with scripts:

* Allow to disable auto-opening tabs when you click on databases, tables, etc. Those tabs have great info, but they could be open with a double click or right click > properties. When editing scripts, you may be using the left tree just for reference or dragging names, you don't want your script to disappear on every click.
* Allow to close the Host tab, or even don't open it by default, leaving more space for script tabs (could be open again by clicking on the server on the left).


Thanks for this great and very useful project. Even without good script editing support, it is currently the best GUI for MySQL, beating commercial ones. Hope to see it getting even better.

Please take into account that the more average user is not just writing SQL scripts. Instead, I designed Heidi to meat multiple everyday tasks of web developers. If you just need a console, use the MySQL command line, or even start it from HeidiSQL (Tools > Launch command line). But the good news is, you can resize the SQL editors vertically and horizontally. Did you notice that?

Hi,

Yes, I noticed the resize thing. Still, the features I'm suggesting shouldn't change anything for the every day user. At least the first four won't affect anything other than make the app more like every other app out there.

Currently, I find it almost impossible to work with scripts inside Heidi. I just edit them on Notepad++ and copy to heidi, which makes the workflow very odd.

I noticed that once you stop on the query editor, clicking on the tabs won't hide the editor as it does with other windows. But the changing of tabs on every click makes it really hard to have multiple files open.

Just to understand this, at least for the first 4 items, do you think any of them is a possibility?

Just for the record, I'd like to expose how I usually work to see if you have any tips.

For every database I have worked on, we always use scripts for everything. There are never changes in production with table designers, modelers, etc. We can do a change during development using a designer, but the resulting code will get compiled to a script that will do all the necessary things.

When you do multiple changes, usually from multiple people, you end up with one or more scripts, and eventually you will need to fix or change stuff in the scripts to make them work correctly together. There are also lots of changes involving data manipulation where your code is like a procedure, you create tables, do loops and other stuff to arrange the data during a migration.

This usually means having a bunch of scripts with a thousand lines each, most of the time hand-coded with updates, fixes, create tables, etc.

In SQL Server, Studio Management is excellent at this. You just open multiple scripts, edit what you want, run the queries one by one during test, make sure they work correctly before sending to production.

In MySQL, there is not a single tool to do this kind of thing. Heidi is the only GUI that seems usable (and yes, I tried Navicat), but its support for writing scripts is very poor, and this seems to be an issue with MySQL, as for other platforms like Postgres, Oracle, Firebird, and even SQL Lite, the tools are more oriented for scripting SQL.

This flow is very common for any kind of database, but I usually see people in the mysql world doing schema upgrades by hand, probably because the tools don't help.

So, probably my question is, do you as the developer feel that this kind of workflow should be somehow supported by Heidi, or do you believe the tool is already good enough the way it is and you don't want to change anything in this respect?

I could come up with other ideas if those have blockings, but would be nice to know if there is any interest in this kind of thing.

r4476 moves file related commands to the "File" menu. So far what I can do for you. For the other things I must say it's by intention as it currently is.

The query editor for example is resizable, so where's the problem when maximizing it once? You say it's nearly impossible to work with scripts - that sounds as if you just should take some time to "warm up" with HeidiSQL. HeidiSQL is not just a script editor, and if you begin to use other tools inside it, you will love it as everything is only one or two clicks away. And that's indeed something which you don't get from SQL Server Management studio. For example Management Studio does not have a user manager, no table designer and no backup dialog. And if all these features are missing in Management Studio, it's totally different from how HeidiSQL works, and it's wrong to compare both as apples and peaches (or bananas in case of Management Studio, if you ask me).

Maybe you are referring to the free express version. I haven't used that in ages, but the regular version has all those features. Anyway, my intention is not to discuss MS products, it was just an example.

I appreciate you moving the file actions. Should fill a bug report, but I'll just say here: if you open a file and change something, and then open another file, it just replaces the contents and won't ask if you want to save or discard... maybe it needs some checks, regular text editor stuff. Also, going to File > Open twice should open another tab.

I respect your opinion. From what I see, Heidi is exactly what you need to do your work, and you will keep it this way because that is what you like. It is your project, your rules.

Most of my flow with any SQL database is writing or reading SQL. I rarely use designers, and I have a strong opinion that MySQL itself has a really bad reputation because most people using it don't write as much SQL as they should, because the tools don't make it confortable.

Anyway, I found dbForge Studio for Mysql and it has a nice text editor (http://www.devart.com/dbforge/mysql/studio/images/highlights/sql-editing.png) that fits my use case better.

Thanks