Threaded queries and finding a new logo

ansgar posted 7 years ago in News
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.
Rvanlaak posted 7 years ago
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
ansgar posted 7 years ago
No, because of thread complexity and performance overhead I only made user fired queries use there own thread.
Rvanlaak posted 7 years ago
Ok, and is there any chance that the export window also will use its own thread in the near future? smile
ansgar posted 7 years ago
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.
Rvanlaak posted 7 years ago
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.
ansgar posted 7 years ago
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.
4ndy posted 6 years ago
Have you considered always opening a new connection besides the existing one after execution and closing/re-opening when query(thread) finishes?
ansgar posted 6 years ago
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


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.
kalvaro posted 6 years ago
Even worse:


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