I have a simple DGV using as a datasource a BBS connected to a childbo. Relationships all setup properly. Parent filters children. All data is loaded in parentform loading.



Starting with empty data in all tables.



I have tried setting Setdirtyonedit of the childbo instance to false and to true.



I can create a new parent, but on entering any grid I get the following error.



I know I'm missing something very basic here but as I have a dozen of these grids on my form this is a showstopper.



Would really appreciate any suggestions as to what I should be looking at and just what the tricks are to getting a datagridview and a bbs to play nice. For some reason I thought I had this all working and it does seem to not error if the parent isn't new, but on a new parent - BOOM



InvalidOperationException

Operation is not valid because it results in a reentrant call to the SetCurrentCellAddressCore function.



Source : System.Windows.Forms



Stack Trace:

at System.Windows.Forms.DataGridView.SetCurrentCellAddressCore(Int32 columnIndex, Int32 rowIndex, Boolean setAnchorCellAddress, Boolean validateCurrentCell, Boolean throughMouseClick)

at System.Windows.Forms.DataGridView.DataGridViewDataConnection.MatchCurrencyManagerPosition(Boolean scrollIntoView, Boolean clearSelection)

at System.Windows.Forms.DataGridView.DataGridViewDataConnection.ProcessListChanged(ListChangedEventArgs e)

at System.Windows.Forms.DataGridView.DataGridViewDataConnection.currencyManager_ListChanged(Object sender, ListChangedEventArgs e)

at System.Windows.Forms.CurrencyManager.OnListChanged(ListChangedEventArgs e)

at System.Windows.Forms.CurrencyManager.List_ListChanged(Object sender, ListChangedEventArgs e)

at System.ComponentModel.ListChangedEventHandler.Invoke(Object sender, ListChangedEventArgs e)

at MicroFour.StrataFrame.Business.BusinessBindingSource.OnListChanged(ListChangedEventArgs e)

at MicroFour.StrataFrame.Business.BusinessBindingSource.BusinessObject_IsDirtyChanged(Object sender, EventArgs e)

at MicroFour.StrataFrame.Business.BusinessLayer.raise_IsDirtyChanged(Object sender, EventArgs e)

at MicroFour.StrataFrame.Business.BusinessLayer.OnIsDirtyChanged(Boolean DirtyShouldBe)

at MicroFour.StrataFrame.Business.BusinessLayer.SetEditingState(BusinessEditingState EditState, Boolean RefreshControls)

at MicroFour.StrataFrame.Business.BusinessLayer.SetEditingState(BusinessEditingState EditState)

at MicroFour.StrataFrame.Business.BusinessLayer.Add(Boolean CheckSecurity)

at MicroFour.StrataFrame.Business.BusinessBindingSource.IBindingListView_AddNew()

at System.Windows.Forms.CurrencyManager.AddNew()

at System.Windows.Forms.DataGridView.DataGridViewDataConnection.AddNew()

at System.Windows.Forms.DataGridView.DataGridViewDataConnection.OnNewRowNeeded()

at System.Windows.Forms.DataGridView.OnRowEnter(DataGridViewCell& dataGridViewCell, Int32 columnIndex, Int32 rowIndex, Boolean canCreateNewRow, Boolean validationFailureOccurred)

at System.Windows.Forms.DataGridView.OnCellMouseDown(HitTestInfo hti, Boolean isShiftDown, Boolean isControlDown)

at System.Windows.Forms.DataGridView.OnCellMouseDown(DataGridViewCellMouseEventArgs e)

at System.Windows.Forms.DataGridView.OnMouseDown(MouseEventArgs e)

at System.Windows.Forms.Control.WmMouseDown(Message& m, MouseButtons button, Int32 clicks)

at System.Windows.Forms.Control.WndProc(Message& m)

at System.Windows.Forms.DataGridView.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)

Glad you guys got it worked out!

Yep, you have to be carefull on filters as most uses of a BO will go off of the CurrentView, and any changes that bring things into or out of the filter in the middle of a process could cause wonky results (to put it in technical terms.)

To answer Edhy's comment regarding collision detection, collision detection in this environment should still work fine, you would just be opening yourself up to more collisions the longer you went between pulling data from the database and saving the changes back. In other words, it would likely be faster from an access perspective to pull everything you may need back to the database and the save it when you are finished, but if this is a form they will be using for 10 or 20 minutes before hitting the "save" button, you'll want to account for that based on how your users are going to use the system (i.e. how likely it is that someone will edit the same record within that 10 or 20 minutes). 

Our medical application does something similar when you edit a patient record. Since patients are the central component of the system, there is quite a bit of data related to each patient's record.  To account for this, we've split up the editing functions into areas of common use ("Registration" for demographic info, "Ledger" for financial transactions, "Media" for media files, etc), and handle the saving slightly differently as appropriate for each area.

The "Registration" section, for example, pulls all registration information (from about 10 tables) related to the patient at once, and lets you edit any or all of it before hitting save. If you ever navigate off the "Patient Registration" page, however, we ask you to save your changes to persist them back to the database.  In the case of any data collisions, we just use the standard SF Data Collision form and methodolgy, we've just designed those areas of the system to minimize the collisions wherever possible.