![]() Software now useless to me.įaulting application name: MySQLWorkbench.exe, version: 6.3.6.0, time stamp: 0x56698b0dįaulting module name: grt.dll, version: 0.0.0.0, time stamp: 0x566982c0įaulting application start time: 0x01d14efad3b934a9įaulting application path: C:\Program Files\MySQL\MySQL Workbench 6.3 CE\MySQLWorkbench.exeįaulting module path: C:\Program Files\MySQL\MySQL Workbench 6.3 CE\grt.dll Maybe other users can check and verify as well what type of columns and charsets they are using, and when the problem occurs?Īndrew Lugg When I try to add a password to a connection it crashes. I'm guessing this is a varchar column with UTF-8, maybe he can verify this? As soon as he added a varchar to the select query Workbench started crashing. I'm not sure, but I think the problem occurs when selecting data from a table with UTF-8 data.Īs Chris Bishop said in comment before, he was able to select a Bigint without any trouble. On our production server the default charset is utf8. Our schema defenition did not contain any charset definition (sadly). On our development server the default charset is latin1. If I interrupt the query, MySQL Workbench crashes. As soon as I'm selecting 1.000 rows from exactly the same table on our production server MySQL Workbench hangs. On our development database i'm able to select 50.000 rows without any trouble. The databases on those servers are identical, with one minor difference: the charset. MySQL Workbench crashes a lot less, if at all. The thing is, when connected to our development server everything seems to be running a lot better. ![]() I just want to provide this info, although I do not think it really matters. We connect to both servers over TCP/IP over SSH. The versions do not match, because the production database got upgraded a few months ago. I think I might have some information which could point you to the problem.įor a project we have 2 MySQL database, one production (5.6.19-0ubuntu0.14.04.1-log), one development (5.1.73-1). ![]() I did some more research on this problem, because it did not seems like it happened all the time. Michel Dekker I have exactly the same problem with version 6.3.4.0 build 829 (64 bits) on Windows 7 Professional. This is a complete bane, and for any DBA/Developer alike who needs to return a result set larger than 100 rows, basically renders SQL Execution useless. ![]() I have tried everything from choosing a different limit from the drop down in the Query Tabs to explicitly specifying a LIMIT XXXX clause in my queries directly, to changing the Limit Rows threshold in Edit > Preferences > SQL Execution to many different limits, as well as completely turning off the Limit Rows setting globally by unchecking the 'Limit Rows' checkbox. Result sets larger than 100 rows used to return just fine. The same queries which worked fine in previous versions of MySQL Workbench all crash in 6.3.3.0 Build 593 for me, when the result sets are larger than 100 rows. I am running Windows 7 Enterprise 64 bit. Chris Bishop Upgraded to Workbench Commercial 6.3.3.0 Build 593 64bit recently, and any time I try to run any query which returns more than 100 rows, MySQL Workbench completely locks up and I ultimately have to kill the process via Windows Task Manager.
0 Comments
Leave a Reply. |