Query tab refuses to execute

Plasm posted 7 years ago in General

in 3707, the "Execute SQL" icon for the query tabs is sometimes "grayed-out". The hotkey (F9) doesn´t work either.

I can´t figure out, when it appears, but it happened three times this morning. Copying the query-content to a new tab and closing the old one helps.
ansgar posted 7 years ago
The execute button is disabled when there is currently a query running, or if the editor does not contain anything. This is the relevant code which may shed more light on this question:
InQueryTab := QueryTabActive;
Tab := ActiveQueryTab;
NotEmpty := InQueryTab and (Tab.Memo.GetTextLen > 0);
HasSelection := InQueryTab and Tab.Memo.SelAvail;
actExecuteQuery.Enabled := InQueryTab and NotEmpty and (not Tab.QueryRunning);
actExecuteSelection.Enabled := InQueryTab and HasSelection and (not Tab.QueryRunning);
actExecuteCurrentQuery.Enabled := actExecuteQuery.Enabled;
Plasm posted 7 years ago
There was no query running. I was creating a trigger - that doesn´t takes long. Furthermore, the "Cancel running operation" icon was grayed out as well
Plasm posted 7 years ago
Occurred again.
"Execute SQL" and "Cancel running operation" grayed out, SQL log says:
/* 0 rows affected, 0 rows found. Duration for 2 queries: 0,016 sec. */
So I believe, the query isn´t running anymore.

Hmm, just executed the same statements multiple times - no problem. But when I open two tabs, paste the same statement into both tabs, execute tab 1, change to tab 2 and execute tab 2 - the problem occurs (mostly - not every time).

Perhaps it has todo with "... detecting the right tab for a thread." (r3704)
ansgar posted 7 years ago
Not reproducible here. Still thinking your query might not have been finished, as it is moved now in a background thread, and you probably don't notice that the query is still running. Watch the lower right status bar panel please, it should say "Executing query #x of #y..." or so. If it says "Idle" all queries are finished.
Plasm posted 7 years ago

Tried it with this statement:

Do the following steps:
- open 2nd query tab
- copy stmt in 1st query-tab
- copy stmt in 2nd query-tab
- execute 1st tab
- execute 2nd tab

The problem occurs in (approx.) two of three times (at least here).
If you wish, I can post a screenshot.
Plasm posted 7 years ago
Do you have any idea yet?
I wonder why nobody else reports this bug since it happens very often. It´s really tedious.

Tell me, if I can help to locate the source of the problem. Perhaps a screenshot? I´m quite sure that it has to do something with the "thread per tab" feature.
ansgar posted 7 years ago
I tried your reproduction recipe but got nothing unexpected.

A screenshot would only show your disabled execute button would it? Not helpful, I believe your notes above and that you are not lying :)

But you could turn on debug logging in Tools > Preferences > Logging. That brings some more internal details into the log panel which you could paste here for further analysis.
Plasm posted 7 years ago
There´s no difference between the logs if the error occours or not.

/* Ping server ... */
/* 0 rows affected. */
/* Ping server ... */
/* 0 rows affected. */
/* 0 rows affected, 0 rows found. Duration for 2 queries: 0,047 sec. */
/* Ping server ... */
/* 0 rows affected. */
/* Ping server ... */
/* 0 rows affected. */
/* 0 rows affected, 0 rows found. Duration for 2 queries: 0,046 sec. */

First execution was in tab#4, second one in tab#5. Couldn´t reproduce it with the "standard"-tab and tab#2. Perhaps you have to open at least 2 additional tabs?
Plasm posted 7 years ago
Hmm, no. Just appeared with first-tab and tab#2. But it seems that it does not appear with this 2 tabs immediatly after program start (?). Perhaps you have to close at least one tab, before the error occurs? I guess you have to do such a "special action" after program start, before the error occurs (or something like: open at least 3 tabs at the same time).

A propos: just got an error while closing tab#2 from 3 open tabs (first, #2, #3):
date/time : 2011-03-17, 16:52:57, 494ms
computer name : WSJH2
user name : jh <admin>
registered owner : Microsoft / Microsoft
operating system : Windows 7 x64 build 7600
system language : German
system up time : 7 hours 53 minutes
program up time : 23 minutes 22 seconds
processors : 2x Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz
physical memory : 2318/3738 MB (free/total)
free disk space : (C:) 220,33 GB
display mode : 1600x1200, 32 bit
process id : $d80
allocated memory : 66,70 MB
executable : heidisql.exe
exec. date/time : 2011-03-15 09:52
version :
compiled with : Delphi XE
madExcept version : 3.0m beta 1
callstack crc : $00ffffff, $5cabe67b, $5cabe67b
exception number : 1
exception class : EAccessViolation
exception message : Access violation at address 00FFFFFF. Read of address 00FFFFFF.

main thread ($e38):
00ffffff ???
004d621c heidisql.exe Controls TControl.GetClientWidth
005b9d01 heidisql.exe Buttons TSpeedButton.MouseUp
004d8bdc heidisql.exe Controls TControl.DoMouseUp
004d8c58 heidisql.exe Controls TControl.WMLButtonUp
004d823c heidisql.exe Controls TControl.WndProc
004dcb00 heidisql.exe Controls TWinControl.WndProc
0056d3f4 heidisql.exe Forms TCustomForm.WndProc
004d7e60 heidisql.exe Controls TControl.Perform
004dc1a0 heidisql.exe Controls TWinControl.MainWndProc
004d7e60 heidisql.exe Controls TControl.Perform
004dc42c heidisql.exe Controls TWinControl.IsControlMouseMsg
004dc97c heidisql.exe Controls TWinControl.WndProc
004dc1a0 heidisql.exe Controls TWinControl.MainWndProc
004a5720 heidisql.exe Classes StdWndProc
75357df5 USER32.dll DispatchMessageW
005763c3 heidisql.exe Forms TApplication.ProcessMessage
00576406 heidisql.exe Forms TApplication.HandleMessage
00576731 heidisql.exe Forms TApplication.Run
0079774a heidisql.exe heidisql 65 +15 initialization
76d23675 kernel32.dll BaseThreadInitThunk
kalvaro posted 7 years ago
I'm having a problem that looks related. I've noticed it now and then in the latest snapshots (not sure about how to reproduce it). I run a SELECT statement from a query tab and the results panel gets blank. After that, no matter what I do, the panel remains unusable. Furthermore, the "run query" options are disabled.

Steve06 posted 6 years ago
Plasm, I'm having EXACTLY the same problem.
I didn't have it in builds of some months ago.
It's very annoying since I have to close the query tab and open a new one.
Maybe it has something to do with (mis-)communication between MySQL server and HeidiSQL as to whether a query was successfully terminated or not.
roman posted 6 years ago

Same problem here. It's not always reproduceable, but it occurs from time to time (often) and only in the newer release (don't know exactly from which version on). But it didn't occur in former releases.

It's strange. You close the "sleeping" tab, open a new one, copy exactly the same statement in the new tab and it works.

Connection is idle, no query to run.
ansgar posted 6 years ago
Guys, this is quite hard to reproduce. I find myself pressing F9 all the time, with errors in the query, switching to another tab, then back, creating new tab, pasting, F9, switch to first tab again, F9, etc. "Run" button is always active. I'll give it some more time of testing, sigh.
Plasm posted 6 years ago
There needn´t be errors in the query.
Feel free to ask if you have any idea how I can help you.
Steve06 posted 6 years ago
My guess would be it has something to do with the communication between HeidiSQL and the particular server, i.e. Heidi not understanding that a query has finished being processed by the server when in fact it has.

On another note, I don't think it is specific to certain versions of MySQL, since I was able to reproduce the error before and after my upgrade from 5.1.51 to 5.5.10 (Community editions both).
ansgar posted 6 years ago
Should be fixed in r3758
ansgar posted 6 years ago
Just to be complete: The "query finished" method added its result to the wrong tab, plus changing the "query tunning" flag to false on that wrong tab. The method FindQueryTabByThread(Thread) returned this wrong one - but I'm still unsure why. However, the thread now knows the unique number of the tab on which it works.

Another bug I fixed in the same commit was that if the user starts a long query, then clicks a different connection in the database tree, the query profile result suddenly was fetched from the newly selected connection.
Plasm posted 6 years ago
No problem here yet. Seems OK. Thanks a lot!
Steve06 posted 6 years ago
no problem either so far.


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