Bug #70747 All round buggy table "Inserts"
Submitted: 28 Oct 2013 12:05 Modified: 13 Dec 2013 9:38
Reporter: Chris Brown Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Workbench: Modeling Severity:S2 (Serious)
Version:6.0.7 OS:Windows (7 64 bit)
Assigned to: CPU Architecture:Any
Tags: inserts

[28 Oct 2013 12:05] Chris Brown
Description:
The "Inserts" tab of Workbench has always been incredibly buggy for me all round - but especially in conjunction with forward engineering.

It's hard to make the errors clear exactly because there are so many and they are so sporadic.  I'll recall what I can, I hope it's useful.

Forward Engineering, for example, with my current project:

If I untick the generate inserts box, it builds perfectly every time.
If I leave it ticked, there's roughly a 75% change it will fail with "Operation is not valid because it results in a reentrant call to the SetCurrentCellAddressCore function." - which is displayed twice.  It seems random whether it fails or not, as you can build 10 in a row unchanged with some working and some failing.  There over 10 rows and over 15 columns, if that knowledge is of any use.  It might be helpful to note that the forward-engineering problem started happening more frequently when I added a 17th column to the table.

Alternatively - sometimes the error doesn't show up and instead Workbench completely crashes.  The strange part about this is the "Inserts" column reverts back to what it was before you started editing, even if it was successfully committed and the model was saved before the crash.

These problems only seem to crop up after some editing of Inserts has been done.

Another unrelated (non-forward engineering) problem is Workbench sometimes crashes if there's a lot of columns for an Insert and you simply click on a cell to edit it (again, I think this might relate to having over 15-20 columns).

Yet another unrelated problem is Workbench sometimes crashes when editing text in Inserts (rarer) - you know it's coming because shortly before the cursor disappears, then when you click on another row, it crashes.

Every day that I work with the Inserts column, I can guarantee it will crash at least once, especially with forward engineering.  And considering that it effectively "unsaves" the Inserts tab if it crashes, it can be a mindless process of repeatedly reopening Workbench, copying all the data you've lost and trying again until, by chance, it works.
I had hoped it would be improved with some of the recent releases, but there has been no change, so maybe the problems aren't known.

How to repeat:
I'm not sure of the exact cause of the bugs.
I appreciate this probably isn't very helpful, but I'm just as disappointed that there's not a accurate way to recreate the issue (that I've yet to discover).
[28 Oct 2013 12:35] MySQL Verification Team
Thank you for the bug report. Are you able to provide the model project file (private if you wish)?. Thanks.
[28 Oct 2013 16:43] Chris Brown
I've added my file - hope it helps.
Please remove the file once you're finished with the bugs.  No rush, as long as it's not on here forever.

It isn't glitching very much for me at the moment - it comes and goes.  But I just did a bit of fiddling around with it there before I sent it off and it crashed when I added then removed a row from the config table (without committing them).

The config and effects tables are the ones that use the Insert tabs.  It usually crashes if I edit them a lot (moreso effects, since there's more than 1 row) then forward engineer with Ctrl+Shift+G, at the generation stage.  It's working fine for me at the moment, but like I said, it's quite unpredictable.
[29 Oct 2013 21:21] MySQL Verification Team
Thank you for the feedback. I was able to repeat only to execute the Forward Engineering after to make some new inserts.

Exception = System.InvalidOperationException
Message = Operation is not valid because it results in a reentrant call to the SetCurrentCellAddressCore function.
FullText = System.InvalidOperationException: Operation is not valid because it results in a reentrant call to the SetCurrentCellAddressCore function.
   at System.Windows.Forms.DataGridView.SetCurrentCellAddressCore(Int32 columnIndex, Int32 rowIndex, Boolean setAnchorCellAddress, Boolean validateCurrentCell, Boolean throughMouseClick)
   at System.Windows.Forms.DataGridView.set_CurrentCell(DataGridViewCell value)
   at System.Windows.Forms.DataGridView.OnClearingColumns()
   at System.Windows.Forms.DataGridViewColumnCollection.Clear()
   at MySQL.Controls.GridView.ProcessModelChange()
   at MySQL.Grt.Db.RecordsetView.ProcessModelChange()
   at MySQL.Grt.RunWrappedDelegate0<int\,int\,MySQL::Grt::DelegateSlot0<int\,int>::ManagedDelegate>.native_callback()
   at boost.detail.function.function_invoker0<int (__cdecl*)(void),int>.invoke(function_buffer* function_ptr)
   at MySQL.Grt.ListModel.refresh()
   at MySQL.GUI.Workbench.Plugins.DbMysqlTableEditor.insertsTabPage_Enter(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnEnter(EventArgs e)
   at System.Windows.Forms.TabPage.OnEnter(EventArgs e)
   at System.Windows.Forms.TabPage.FireEnter(EventArgs e)
   at System.Windows.Forms.TabControl.OnEnter(EventArgs e)
   at MySQL.Controls.FlatTabControl.OnEnter(EventArgs e)
   at System.Windows.Forms.Control.NotifyEnter()
   at System.Windows.Forms.ContainerControl.UpdateFocusedControl()
[16 Nov 2013 22:03] Fotis Kokkoras
This bug is similar to #70627. There is a video there demostrating the bug.
[11 Dec 2013 20:10] Armando Lopez Valencia
Posted by developer:
 
FIXED
Verified in:
Ubuntu13.10x86
Windows 8x64
WB 6.1.0.11452
Wasn't able to reproduce after several attempts, inserts from a Model is working as expected (even with the model provided).
[13 Dec 2013 9:04] Philip Olson
Fixed as of the upcoming MySQL Workbench 6.0.9 release, and here's the changelog entry:

The "Inserts" tab under "Forward Engineering" would sometimes unexpectedly
fail.

Thank you for the bug report.
[13 Dec 2013 9:38] Chris Brown
Many thanks guys.  Strangely I've not noticed the problem again since, without the fix.  Must have been caused by a fairly specific model state.