MySQL Bugs: #61531: trying to load a 93M script (big table) created by dumping a table

Bug #61531	trying to load a 93M script (big table) created by dumping a table
Submitted:	16 Jun 2011 0:44	Modified:	20 Jun 2011 9:35
Reporter:	Alex Wielhouwer	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Workbench: SQL Editor	Severity:	S2 (Serious)
Version:	5.2.34CE.7780	OS:	Windows
Assigned to:		CPU Architecture:	Any

Description:
Exception = System.Runtime.InteropServices.SEHException
Message = External component has thrown an exception.
FullText = System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.
   at new(UInt32 )
   at std._Allocate<char>(UInt32 _Count, SByte* __unnamed001)
   at std.allocator<char>.allocate(allocator<char>* , UInt32 _Count)
   at std.basic_string<char,std::char_traits<char>,std::allocator<char> >._Copy(basic_string<char\,std::char_traits<char>\,std::allocator<char> >* , UInt32 _Newsize, UInt32 _Oldlen)
   at std.basic_string<char,std::char_traits<char>,std::allocator<char> >._Grow(basic_string<char\,std::char_traits<char>\,std::allocator<char> >* , UInt32 _Newsize, Boolean _Trim)
   at std.basic_string<char,std::char_traits<char>,std::allocator<char> >.assign(basic_string<char\,std::char_traits<char>\,std::allocator<char> >* , SByte* _Ptr, UInt32 _Count)
   at std.basic_string<char,std::char_traits<char>,std::allocator<char> >.assign(basic_string<char\,std::char_traits<char>\,std::allocator<char> >* , SByte* _Ptr)
   at std.basic_string<char,std::char_traits<char>,std::allocator<char> >.{ctor}(basic_string<char\,std::char_traits<char>\,std::allocator<char> >* , SByte* _Ptr)
   at MySQL.?A0x27dc8298.NativeToCppStringRaw(basic_string<char\,std::char_traits<char>\,std::allocator<char> >* , String str)
   at MySQL.Grt.Db.Sql.Sql_editor.sql(String sql)
   at MySQL.Grt.Db.Sql.SqlEditor.TextModified(Object sender, TextModifiedEventArgs e)
   at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
   at ScintillaNet.Scintilla.OnTextInserted(TextModifiedEventArgs e)
   at ScintillaNet.Scintilla.FireModified(NativeScintillaEventArgs ea)
   at ScintillaNet.Scintilla.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

if it creates the script, it should run the script, even if it means partial loads of the script

How to repeat:
export a big table then try to reimport it

Suggested fix:
perhaps limit and split scripts created or step through large script files without loading the entire file

Which exactly version 5.2.XX are you using?. Thanks.

version updated above

How exactly you tried to load that script? In SQL Editor or in Administration part?

Tried first from the administrator section. When that failed, I tried manually from the sql query tools

Please, send the output of Help > System Info menu item.

MySQL Workbench CE for Windows version 5.2.34

Configuration Directory: C:\Users\win7sql\AppData\Roaming\MySQL\Workbench

Data Directory: C:\Program Files\MySQL\MySQL Workbench 5.2 CE

Cairo Version: 1.8.8

Rendering Mode: OpenGL is not available on this system, so GDI is used for rendering.

OS: Microsoft Windows 7  Service Pack 1 (build 7601), 32-bit

CPU: AMD Athlon(tm) II X4 630 Processor, 2.0 GiB RAM

Current user language: English (Canada)

Note: shouldn't make a difference but this is a virtual machine running on a Hyper-V server.

Please, try to load using the "Import from Self-contained file" option in: Server Administration -> Data export and restore -> Import from Disk.

Unfortunately,  I have had to trash the system and start over to at least try to keep the project on track. Reloading the data again from its original source. 

All this because of some index corruption that (innodb) that could not be solved by a simple drop index, create index.  (wouldn't let me drop it after I had to set the innodb_force_recovery = 4 to actually start the system) seemed a bit chicken and egg in terms of corruption recovery.

This is a duplicate of bug #55312