| Bug #64003 | "Connection canceled" appears repeatedly when attempting to connect over VPN | ||
|---|---|---|---|
| Submitted: | 11 Jan 2012 21:02 | Modified: | 14 Jun 2013 1:29 |
| Reporter: | William Lipman | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Workbench: SQL Editor | Severity: | S2 (Serious) |
| Version: | 5.2.36, 5.2.37 | OS: | Windows (XP Pro SP3) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | connecting | ||
[11 Jan 2012 21:02]
William Lipman
[12 Jan 2012 17:29]
Valeriy Kravchuk
Just a wild guess... If you have many tables in the database you are connecting to, please, try to increase: DBMS connection keep-alive interval (in seconds): and DBMS connection read time out (in seconds): in Properties > SQL Editor. I wonder if setting at least the first one to, say, 120, will change anything.
[12 Jan 2012 17:45]
William Lipman
Valeriy Kravchuk: Thanks for the tips, but I just checked and the default "keep alive interval" was already set to 600 seconds [5 minutes] and so was the "read timeout". These are much longer than required in this case. My problem is not "what happens AFTER connection" but "getting connected in the first place." The "Connection canceled" error appears after only about ten to fifteen seconds, so I think there is something in the initial connection protocol logic that needs to be less sensitive. Not knowing enough about the server side of things, I have no idea whether the server itself is canceling the connection attempt, and, if so, why it would do that. I wonder if the connection protocol requires some sort of positive response from the server within an interval that SQL Editor can control? It may have been designed for access to servers that are either (a) local or (b) directly connected over the Web--without a VPN in the middle. The culprit could easily be extra latency introduced by the VPN which pushes the connection time beyond the SQL Editor's tolerance.
[12 Jan 2012 18:11]
William Lipman
Correction: Of course I meant that 600 seconds = TEN minutes, not five minutes. Again, this is longer than needed once connected.
[16 Jan 2012 16:14]
Armando Lopez Valencia
Hello William. Can you please try with the new 5.2.37 WB version and let us know if you still have the same problem. thanks.
[8 Feb 2012 15:51]
Stephen Punak
This bug is also exhibiting when connecting to any of my databases through ssh. It has made version 5.2.37 almost unusable on Windows. I saw a recommendation to try 5.2.37 WB. I would like to try that version, but am not sure where to get it.
[8 Feb 2012 19:19]
William Lipman
The last report on this bug suggests that perhaps the problem lies within the database client driver software, rather than the MySQL Workbench SQL Editor application--or that there is a timeout parameter within the driver, at session connect time within the SQL Editor, and it is being allowed to default to an in interval that is too short for some network protocols or topologies with unusual latencies. Once this part of the code has been identified, and if the parameter is broken out in the driver API, then it must not be allowed to default. It should be specified at an increased value, at the very least. In that case, a final solution to put this issue to bed would probably involve adding this timeout parameter to the SQL Editor's options menu, so the SQL WorkBench application can control the timeout interval. Of course, if the parameter is not included in the client API for the driver then it would have to be modified first. A final comment is that a parallel application of Oracle is "SQL Developer" and I have never experienced this issue under that platform, which employs a JDBC/ODBC driver in the database client layer.
[28 Mar 2012 13:27]
Bob Dankert
I have experienced this issue quite frequently, in fact daily - although I am never connecting over a VPN. I have experienced it on multiple computers, on multiple networks, connecting to remote MySQL servers (just over the internet, no vpn) as well as local MySQL servers. It happens where I will double click to connect to a server using SQL Development, but it will display connection cancelled in the status bar. It usually connects the second attempt, but sometimes takes 3+ times trying to open it. Repeat enough times and it always connects eventually. Also as originally reported, once it opens it never has issues with any queries or commands. I'm not certain on this, but it seems to happen more often after I first start up WorkBench. After I have established a connection once to a database on a server, subsequent connections to the same server (different database) do not seem to have the problem. Let me know if there is anything else I can provide to help with this issue.
[28 Mar 2012 13:28]
Bob Dankert
I should also add that this is happening in 5.2.37 for me...
[23 Apr 2012 12:56]
Nate Jensen
This same exact problem happens repeatedly for me, but only when connecting over Windows Remote Desktop to a remote server. My client is Win7, remote server is Win2008. MySQL Workbench is being run directly on the server, connecting locally to itself. When I launch Workbench on my local Win7 to connect either to my local MySQL server instance, or a remote instance I have access to, I've never had this problem. Only when remoting into Win08 and trying to connect locally from that server. I sure wish MySQL would fix this. The Workbench version is 5.2.37 CE.
[23 Apr 2012 13:17]
Nate Jensen
I just made a discovery. If I un-maximize my Windows Remote Desktop connection window and double-click my saved connection in Workbench, the problem doesn't happen and I connect immediately. Maybe this problem is some artifact of being in RD full screen mode.
[15 May 2012 17:07]
Chris Lehnert
Same happened to me. This might seem obvious to some, but I fixed it by updating my Windows Firewall.
[15 Jul 2012 20:00]
mohamed banaouas
ubuntu 12.04 Precise 64 bit, MySql Workbench 5.2.40 CE, Revision 8790 Me too, sometimes, I get "connection canceled, and it'is very annoying ! I also noticed If I un-maximize MySqlWorkbench main Window and double-click my saved connection, the problem disappears and Sql Query window is normally opened.
[21 Jul 2012 17:18]
Gareth Edwards
Just to second Mohammed: Suddenly started getting this repeatedly whilst using 5.2.37 on an Amazon EC2 instance connecting via localhost. Saw his report, un-maximised the window and it connected straight away.
[2 Aug 2012 16:43]
Alfredo Kojima
Bug #65985 is a duplicate
[2 Aug 2012 16:48]
Alfredo Kojima
Bug #65993 is a duplicate
[18 Aug 2012 20:24]
David Dykstra
I am using MySQL workbench 5.2.42 on Windows XP connected to using VPN. I connect to the server via VPN and run the Workbench on the virtual server. I had this exact same issue, however I found a workaround.
1. Do not save the password in the the vault (must be entered manually every time)
2. Delete all Workbench cache files and log files (for me it was located at the following)
-C:\Documents and Settings\"Username"\Application Data\MySQL\Workbench...
-empty \cache\
-empty \log\
3. Try to connect again
This worked for me!
[29 Aug 2012 3:09]
Ana Ruiz
I have installed for the first time mysql 5.5.27.2, and I have the same problem, the answer is ¿How do I fix it?. I need the newer version of mysql and I tried to unistall and re-install it, but it doesn't works.
[20 Sep 2012 8:52]
Jens Albrecht
I just had the same problem on a Windows VM on Mac Parallels Desktop. I am running 5.2.43. It seems to be a problem with the network interface. I tried to use not localhost but the external IP address. After I opened up remote connections with GRANT ALL ON *.* to root@’%’ IDENTIFIED BY ‘your-root-password’; it worked. Suprisingly also with localhost.
[20 Sep 2012 9:02]
Jens Albrecht
Sorry, it just worked a couple of times and now it's back to "connection cancelled".
[27 Sep 2012 2:51]
David Tanzer
I'm having the same trouble. And, interestingly, if I click on "Open Connection to Start Querying" instead of double clicking on my saved connection data, the Workbench will crash when I click "OK" in the Connect to Database dialog. My version is 5.2.43. I have 5.2.33 on a different computer, and that works fine.
[10 Oct 2012 17:47]
Jerry Royer
Still happening for me too. Intermittent, meaning I can double click once, put in my password and see 'connection cancelled' in the bottom left, but try double clicking a few more times and it will go in with no password prompting. I went ahead and brought up the command line and granted all permission to % (then a separate grant for localhost, not sure if that was needed or not) and now it will never go in to the connection. Using version 5.5.19.0. I realize this bug string is for an earlier version, but it's still going strong... Windows Server 2008 R2.
[24 Oct 2012 13:08]
MySQL Verification Team
http://bugs.mysql.com/bug.php?id=67348 marked as duplicate of this one.
[4 Dec 2012 14:10]
Tim Buches
my problem is strictly SQL Development in Workbench, "Connection Cancelled". Admin in Workbench connects just fine. in fact every SQLdevelopment attempt to connect shows a connection to the database in admin. its as if the SQL development GUI is failing but the connection persits.
[4 Dec 2012 14:12]
Tim Buches
by the way MySQL Workbench version 5.2.44 CE
[6 Dec 2012 17:29]
Bill Weir
I can verify this issue is still present in v5.2.44. The machine in question is running Server 2008 R2 with Workbench installed which I am connecting to via RDP. I receive the 'connection cancelled' message when double clicking the 'Local instance MySQL'. If Workbench is maximized, the attempt fails. If workbench is not maximized failure is intermittent. It's not consistant, but it seems that resizing your Workbench window larger increases the odds of receiving the connection canceled message. I have however had the SQL Editor window open, closed it, then attempted to reopen and received the connection canceled message even without resizing the main window.
[14 Dec 2012 0:32]
William Wynn
This has been happening on one of our Windows 2008 R2 servers connecting to a local database since workbench was released up to the current 5.2.44 CE. I have to launch Query Browser which connects without any issue. Windows firewall is disabled.
[17 Jan 2013 10:43]
Mike Lischke
For further examination of this problem we'd need the log file as it is right after the connection attempt failed. So for everybody on this report: can you try with a fresh start of WB and try to open a connection? As soon as this fails go to the Help menu and locate or open the log file. Don't close WB, just leave it running. Then attach this file here. You can make it private to avoid sharing your machine details with the world. Thanks.
[17 Jan 2013 14:52]
Bob Dankert
I added a log file for the developers that shows a couple connections that cancelled on me. I started clicking on a bunch of connections and of the 10 connections or so I tried, all but 2 connected. The other two showed connection cancelled in status bar, and the log shows: "08:45:09 [INF][ WBContext]: Connection to Connection4-NTF cancelled by user: canceled". I can assure you that the connection was not cancelled by me - I didn't hit any keys on the keyboard and I had only double clicked on the connection, which is very far from where the "Cancel" button is on the popup box.
[28 Jan 2013 15:43]
Mike Lischke
Bob, William, thanks for your log files. I'm sorry, but I forgot to mention that you must increase the log level to have meaningful output in the logs. Please forgive my forgetfulness. In order to increase the level you must run WB from a command prompt (or, on Windows, use a link to the exe and add the required parameter in the settings of the link). Add -log-level=debug2 (on Mac/Linux use --log-level=debug2, i.e. a double dash). Then try opening WQE sessions until they are shown as canceled again. This time the log hopefully contains info *where* it was canceled, actually. Thanks.
[28 Jan 2013 16:01]
Bob Dankert
After attempting a large number of connections with the debug level increased, I Was only able to get a connection cancelled message twice, and one of them was my fault. The first occurred on an attempt to connect to database that had some autosaved data with it and the connection failed: 09:48:49 [DB1][ mforms backend]: Looking up password for 'account'@'Mysql@ip_address:3306' has succeeded 09:48:50 [DB2][ AutoCCache]: Using autocompletion cache file C:\Users\bob.dankert\AppData\Roaming\MySQL\Workbench/cache/ConnectionName.cache 09:48:50 [DB1][ AutoCCache]: refresh schema cache for 09:48:50 [DB2][ AutoCCache]: entering worker thread 09:48:50 [DB2][ AutoCCache]: Found 4 schemas. 09:48:50 [DB2][ AutoCCache]: leaving worker thread 09:48:51 [INF][ WBContext]: Connection to ConnectionName cancelled by user: canceled Again, I did not click anything to cancel the connection. The next one that said "Connection cancelled by user" was my fault, as the hostname was entered incorrectly for the connection. However, it should say that the connection failed instead of always saying the connection is cancelled by the user: 09:52:14 [ERR][ WQE backend]: Got an exception during connection: Can't connect to MySQL server on 'hostname2.com' (10060) 09:52:14 [INF][ WBContext]: Connection to ConnectName2 cancelled by user: canceled
[28 Jan 2013 16:18]
Bob Dankert
After giving up and assuming that all of the connections would just succeed, I was able to get a large number of failed connections to one of my database connections. I had 6 failed connections, each reported as cancelled by user. I was able to get it to connect by trying a different connection and then going back to the one that had been failing. The log is attached (set to private). I removed a number of successful connections from the log, as well as changed some database names to protect some information.
[28 Jan 2013 16:23]
Mike Lischke
Great, thanks Bob! Can you do another test: disable auto completion in the preferences. I don't see how that is related to the cancellation, but everytime the problem comes up the last action before that was looking something up in the auto completion cache. Maybe that gives us a clue.
[28 Jan 2013 20:35]
William Wynn
I got the same autocompletion note in my log, so I disabled it and got this. First is with autocompletion and second is without. 12:16:04 [INF][ Workbench]: UI is up 12:16:05 [INF][ Workbench]: Running the application 12:16:13 [INF][ SSH tunnel]: Starting tunnel 12:16:13 [DB2][ python context]: About to pyrun 'C:\Program Files (x86)\MySQL\MySQL Workbench 5.2 CE\sshtunnel.py' 12:16:13 [DB1][ mforms backend]: Looking up password for 'remoteuser'@'Mysql@127.0.0.1:3306' has succeeded 12:16:13 [DB2][ AutoCCache]: Using autocompletion cache file C:\Users\administrator.REMOVED\AppData\Roaming\MySQL\Workbench/cache/cioremote.cache 12:16:13 [DB1][ AutoCCache]: refresh schema cache for 12:16:13 [INF][ WBContext]: Connection to cioremote cancelled by user: canceled 12:16:13 [DB2][ AutoCCache]: Waiting for worker thread to finish... 12:16:13 [DB2][ AutoCCache]: entering worker thread 12:16:13 [DB2][ AutoCCache]: leaving worker thread 12:16:13 [DB2][ AutoCCache]: Worker thread finished. 12:18:14 [DB2][ grt]: wb.form.showOptions finished in 54.24s 12:18:17 [DB1][ mforms backend]: Looking up password for 'remoteuser'@'Mysql@127.0.0.1:3306' has succeeded 12:18:17 [DB1][ SqlEditor]: Code completion is disabled, so no name cache is created 12:18:18 [INF][ WBContext]: Connection to cioremote cancelled by user: canceled
[28 Jan 2013 20:40]
William Wynn
I tried one more time with log-level=debug3 and autocompletion disabled: 12:31:08 [INF][ Workbench]: UI is up 12:31:09 [INF][ Workbench]: Running the application 12:31:12 [DB3][ WQE backend]: Connecting SQL editor... 12:31:12 [INF][ SSH tunnel]: Starting tunnel 12:31:12 [DB2][ python context]: About to pyrun 'C:\Program Files (x86)\MySQL\MySQL Workbench 5.2 CE\sshtunnel.py' 12:31:12 [DB1][ mforms backend]: Looking up password for 'remoteuser'@'Mysql@127.0.0.1:3306' has succeeded 12:31:12 [DB1][ SqlEditor]: Code completion is disabled, so no name cache is created 12:31:12 [DB3][ WQE backend]: Connection to SQL editor succeeded 12:31:12 [DB3][mforms::Utilities]: run_cancelable_wait_message returned false 12:31:12 [INF][ WBContext]: Connection to cioremote cancelled by user: canceled
[14 Feb 2013 4:57]
Joe Harper
I also have then problem, when I RDP into a windows 2012 server, I go to connect and it just shows "Connection cancelled" as soon as I try. However, a connect to the server shows, so it doesn't seem to be anything to do with the actual server. From the log file it looks like the waiting dialog sends back a cancel message, as though the cancel button had been clicked, even though it wasn't actually clicked. Which could explain why it seems to be related to using RDP. I would say this is an interface bug, to do with the dialog box. Below is the debug3 log: 20:25:01 [INF][ Workbench]: UI is up 20:25:01 [INF][ Workbench]: Running the application 20:25:04 [DB1][ mforms managed]: Running a cancelable wait message 20:25:04 [DB2][ mforms managed]: Starting the task 20:25:04 [DB2][ mforms managed]: Running the HUD window 20:25:04 [DB3][ WQE backend]: Connecting SQL editor... 20:25:04 [INF][ SSH tunnel]: Starting tunnel 20:25:04 [DB2][ python context]: About to pyrun 'C:\Program Files (x86)\MySQL\MySQL Workbench 5.2 CE\sshtunnel.py' 20:25:04 [DB1][ mforms managed]: Running slot on main thread ( waiting for it) 20:25:04 [DB2][ mforms managed]: Cross thread invocation required 20:25:04 [DB2][ mforms managed]: Running slot on main thread 20:25:04 [DB1][ mforms managed]: Looking up password for service: Mysql@localhost:3306, account: root 20:25:04 [DB1][ mforms managed]: Loading password cache 20:25:04 [DB1][ mforms managed]: Get special folder 20:25:04 [DB2][ mforms managed]: Decrypting password data 20:25:04 [DB2][ mforms managed]: Filling password cache 20:25:04 [DB1][ mforms managed]: Unloading password cache 20:25:04 [DB1][ mforms backend]: Looking up password for 'root'@'Mysql@localhost:3306' has failed 20:25:04 [DB1][ mforms managed]: Running slot on main thread ( waiting for it) 20:25:04 [DB2][ mforms managed]: Cross thread invocation required 20:25:04 [DB2][ mforms managed]: Running slot on main thread 20:25:04 [DB1][ mforms backend]: Forgetting password for 'root'@'Mysql@localhost:3306' 20:25:04 [DB1][ mforms managed]: Loading password cache 20:25:04 [DB1][ mforms managed]: Get special folder 20:25:04 [DB2][ mforms managed]: Decrypting password data 20:25:04 [DB2][ mforms managed]: Filling password cache 20:25:04 [DB1][ mforms managed]: Unloading password cache 20:25:04 [DB1][ mforms backend]: Creating and showing password dialog 20:25:04 [DB1][ mforms managed]: Hiding the wait message 20:25:04 [DB2][ mforms managed]: Wait message was visible, finishing it 20:25:04 [DB2][ mforms managed]: Returning main form 20:25:09 [DB2][ mforms managed]: HUD window returned with code: 1 20:25:09 [DB1][ mforms managed]: Running a cancelable wait message 20:25:09 [DB2][ mforms managed]: Running the HUD window 20:25:09 [DB2][ AutoCCache]: Using autocompletion cache file C:\Users\Administrator\AppData\Roaming\MySQL\Workbench/cache/Local_MySQL56.cache 20:25:09 [DB1][ AutoCCache]: refresh schema cache for 20:25:09 [DB3][ AutoCCache]: creating worker thread 20:25:09 [DB3][ WQE backend]: Connection to SQL editor succeeded 20:25:09 [DB1][ mforms managed]: Explicit cancelation of the wait message 20:25:09 [DB2][ AutoCCache]: entering worker thread 20:25:09 [DB3][ AutoCCache]: will fetch '' 20:25:09 [DB2][ AutoCCache]: Found 4 schemas. 20:25:09 [DB2][ mforms managed]: HUD window returned with code: 2 20:25:09 [DB2][ mforms backend]: run_cancelable_wait_message returned false 20:25:09 [INF][ WBContext]: Connection to Local MySQL56 cancelled by user: canceled 20:25:10 [DB2][ AutoCCache]: Waiting for worker thread to finish... 20:25:10 [DB2][ AutoCCache]: leaving worker thread 20:25:10 [DB2][ AutoCCache]: Worker thread finished. 20:26:08 [DB1][ mforms managed]: Opening the URL: C:\Users\Administrator\AppData\Roaming\MySQL\Workbench/log/wb.log
[19 Feb 2013 19:17]
Michael Lant
I have just upgraded to 5.2.47 and I can no longer use workbench. I had issues with the previous version as well. I don't recall the version number, but it was installed about three weeks ago using the latest download from MySQL. The problems this time around are much worse than in the previous build and I can find no way to work around them. In the previous build, I found I could get around the problems by deleting all of the SQL connections, closing, restarting and then creating new SQL connections. That does not work in this build. As well, various combinations of deleting, creating new and attempting to open the new connections will cause Workbench to either crash or freeze. This build is unusable. Michael
[19 Feb 2013 19:56]
Michael Lant
After trying for over two hours to get 5.2.47 to work, I finally rolled back to 5.2.46 and MySQL Workbench is usable. I can open DB connections, administer import/export, etc... and no crashes so far. Michael
[4 Apr 2013 13:04]
IOANNIS OIKONOMOU
I am having exactly the same problem on Win 7 x64 with Workbench 5.2.47. Opening Server Admin works always, while opening Query Editor only rarely. Usually if Workbench is down for quite some time and I open it for the first time it works! If I close the application and open it again it does not work, no matter how many times you open it in a row. How can we tackle this issue? Thanks, Ioannis
[8 Apr 2013 21:37]
Fred Smith
The workaround mentioned by David Dykstra above worked for me.
[8 Apr 2013 21:42]
Michael Lant
Hi Ioannis, I have found only one thing that works consistently. If I open Server Admin first, it seems to jog something and then I can open the Query Editor. Michael
[8 Apr 2013 22:37]
IOANNIS OIKONOMOU
Thanks Michael. I will try this tomorrow. Ioannis
[11 Jun 2013 2:36]
Tom Thorp
To All, I have come across this same issue also with MySQL Workbench 5.2.47 . This has only happened to one installation I've done so far, the only difference been I had initial problems installing the add-on components necessary to install Workbench. I will experiment if the installation was part of the problem. (FYI, it is on a Windows 2008 R2 Server on a VMWare environment.) One curious thing I've found during my testing, is that the SQL Editor logs onto the MySQL Server with no password, even though I was using a password to log in, and regardless if it was successful or not. Here is a copy of my General Log file. The first time, I got a 'Connection cancelled' error. After resizing the workbench window (which one user suggested) and retrying, Workbench was successful in logging in. C:\MySQL\v5.5.21\bin\mysqld, Version: 5.5.21-log (MySQL Community Server (GPL)). started with: TCP Port: 3702, Named Pipe: MySQL Time Id Command Argument 130611 12:08:01 48 Connect dbroot@PGHQDC-SLAVE01.ClassicHolidays.com.au on 48 Connect Access denied for user 'dbroot'@'PGHQDC-SLAVE01.ClassicHolidays.com.au' (using password: NO) 130611 12:08:12 49 Connect dbroot@PGHQDC-SLAVE01.ClassicHolidays.com.au on 49 Query set autocommit=1 49 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 49 Query SHOW SESSION VARIABLES LIKE 'lower_case_table_names' 49 Query SELECT current_user() 49 Query SET CHARACTER SET utf8 49 Query SET NAMES utf8 49 Query SET SQL_SAFE_UPDATES=1 49 Query SELECT CONNECTION_ID() 49 Query set autocommit=1 50 Connect dbroot@PGHQDC-SLAVE01.ClassicHolidays.com.au on 50 Query set autocommit=1 50 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 50 Query SHOW SESSION VARIABLES LIKE 'lower_case_table_names' 50 Query SELECT current_user() 50 Query SET CHARACTER SET utf8 50 Query SET NAMES utf8 50 Query SET SQL_SAFE_UPDATES=1 50 Query SELECT CONNECTION_ID() 50 Query set autocommit=1 50 Query SHOW SESSION VARIABLES LIKE 'sql_mode' 50 Query SELECT current_user() 50 Quit 49 Quit 130611 12:08:21 51 Connect dbroot@PGHQDC-SLAVE01.ClassicHolidays.com.au on 51 Connect Access denied for user 'dbroot'@'PGHQDC-SLAVE01.ClassicHolidays.com.au' (using password: NO) 130611 12:08:28 52 Connect dbroot@PGHQDC-SLAVE01.ClassicHolidays.com.au on 52 Query set autocommit=1 52 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 52 Query SHOW SESSION VARIABLES LIKE 'lower_case_table_names' 52 Query SELECT current_user() 52 Query SET CHARACTER SET utf8 52 Query SET NAMES utf8 52 Query SET SQL_SAFE_UPDATES=1 52 Query SELECT CONNECTION_ID() 52 Query set autocommit=1 53 Connect dbroot@PGHQDC-SLAVE01.ClassicHolidays.com.au on 53 Query set autocommit=1 53 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 53 Query SHOW SESSION VARIABLES LIKE 'lower_case_table_names' 53 Query SELECT current_user() 53 Query SET CHARACTER SET utf8 53 Query SET NAMES utf8 53 Query SET SQL_SAFE_UPDATES=1 53 Query SELECT CONNECTION_ID() 53 Query set autocommit=1 53 Query SHOW SESSION VARIABLES LIKE 'sql_mode' 53 Query SELECT current_user() 52 Query SHOW DATABASES 130611 12:08:29 52 Query SHOW DATABASES 130611 12:08:40 35 Query set global general_log=0 Hopefully this gives someone some further insight into solving this issue. - Tom Thorp IT Administrator Classic Holidays tom.thorp@classicholidayclub.com.au
[14 Jun 2013 1:29]
Philip Olson
Fixed as of the upcoming MySQL Workbench 6.0.2 public beta release, and here's the changelog entry: A connection could fail to connect prematurely and would report "Connection canceled" despite "Test Connection" reporting a valid connection. Thank you for the bug report.
