Threaded queries and finding a new logo

User fired queries in a query tab are now processed in a separate thread, which makes the GUI responsive while you run a longer query. Many users asked for that in issue #1509, which is finally fixed now. However, there is one follow up issue, caused in one specific scenario - will be fixed soon. Please update to the latest build to check that out (Help > Check for updates).

Second thing is I am searching for a new logo image, including an application icon in sizes of 16px, 32px and 48px. As a non-designer, I recently tried out some of my own ideas but in the end they all feel slightly wrong and ugly. If you have a good idea or even like to create a logo for HeidiSQL feel free to comment and attach files on issue #2332. The new logo should contain some green area - everything else is up to the creator.

Does the export window also use a separate thread? Often HeidiSQL crashes because tables of > 120 MB are exported through one of my SSH tunnels

No, because of thread complexity and performance overhead I only made user fired queries use there own thread.

Ok, and is there any chance that the export window also will use its own thread in the near future?

For what reason? You would not be able to do more than watch the window - which you can do now also as there are repaint's from time to time.

Am I right if I say that when the export window is a separate thread, you can work while the export is running? In my opinion it would be nice if the user gets more feedback whey big tables are exported.

You are still restricted to run one query at one time, as the server does not allow doing multiple parallel queries in one connection. You would get some "Commands out of sync" error if you would trigger any query.

Have you considered always opening a new connection besides the existing one after execution and closing/re-opening when query(thread) finishes?

Yes, of course I have considered parallel sessions. What is then again problematic is that any session-based stuff would be gone, e.g. some variable you have set before:

SET @myvar:=123

If you query that variable in a later query:

SELECT @myvar

that would return nothing. There is also more affected session based stuff, like when you fire

SELECT FOUND_ROWS()

or

SHOW ERRORS

or the query profile which can be activated via checkbox. So, I'm afraid having parallel sessions would introduce more annoyance than it would heal currently.

Even worse:

START TRANSACTION;
...