Datagrid does not update datasource efficiently

[bidalah]

Hello all,

I have a Windows form datagrid which is bound to a datatable in a
dataset. I want changes that the user performs on the information in
the datagrid to be automatically reflected in the the underlying
datatable.

For the most part this is working. Then sometimes it does not, and I
can't figure out why. It seems that if you change a given datagrid
row, and then click on a different datagrid row, the change generally
gets recorded. If you change a row, and do not click on a different
row, the change is generally NOT recorded, no matter how many cells on
that datagrid row you altered. I don't understand why this is, and
why it is not completely predictable. It also creates a problem for
users who might simply make a change and forget the extra step of
clicking somewhere else.

What is the exact mechanism (event?) which causes the datasource of
the datagrid to be updated? Is there any way to force the datasource
to update itself? Any help would be appreciated.

 

[Earl]

I doubt if you have given enough information to answer your question. I'll
give my ideas though.

Some things have changed between 2003 and 2005, in particular in 2005, you
now have the bindingsource which is far easier to use than the currency
manager. The currency manager takes a bit more code and you have to pay
closer attention to what you are doing with positioning.

So it follows that most of what you ask is totally dependent upon how you
have set up your datagrid and the datasource. If you have this bound to a
bindingsource, then the bindingsource will update as you make changes in the
grid. As the bindingsource changes, it updates the underlying datatable.
It's up to you to write the code to fire the update from the bindingsource
datasource back to the database.

If the grid is NOT bound to a bindingsource, then you have even more
plumbing to write. And I certainly agree that the tricky part of working
with "automatic" updates in the grid can be to ensure that all changes get
recorded. I have taken the easier route and not allowed the user to do
in-grid edits, but to each his own. The grid edits look much cleaner, use
fewer controls, but at the same time, force you to monitor more user events,
both in the grid and out.

If your question is, why are changes not being reflected back into the
database when you make multiple edits in one row of the grid, and the
necessary code is written to fire an update otherwise, then you probably
have a concurrency issue in your stored procedure. In order to do multiple
updates on one row of the grid, every time you fire an update, you must
retrieve that newly updated row of data back to your datagrid datasource,
otherwise your next update in that row will have a concurrency issue (the
row in the grid no longer matches the row in the datatable or no longer
matches the row in the database).

 

[bidalah]

I doubt if you have given enough information to answer your question. I'll
give my ideas though.

Some things have changed between 2003 and 2005, in particular in 2005, you
now have the bindingsource which is far easier to use than the currency
manager. The currency manager takes a bit more code and you have to pay
closer attention to what you are doing with positioning.

So it follows that most of what you ask is totally dependent upon how you
have set up your datagrid and the datasource. If you have this bound to a
bindingsource, then the bindingsource will update as you make changes in the
grid. As the bindingsource changes, it updates the underlying datatable.
It's up to you to write the code to fire the update from the bindingsource
datasource back to the database.

If the grid is NOT bound to a bindingsource, then you have even more
plumbing to write. And I certainly agree that the tricky part of working
with "automatic" updates in the grid can be to ensure that all changes get
recorded. I have taken the easier route and not allowed the user to do
in-grid edits, but to each his own. The grid edits look much cleaner, use
fewer controls, but at the same time, force you to monitor more user events,
both in the grid and out.

If your question is, why are changes not being reflected back into the
database when you make multiple edits in one row of the grid, and the
necessary code is written to fire an update otherwise, then you probably
have a concurrency issue in your stored procedure. In order to do multiple
updates on one row of the grid, every time you fire an update, you must
retrieve that newly updated row of data back to your datagrid datasource,
otherwise your next update in that row will have a concurrency issue (the
row in the grid no longer matches the row in the datatable or no longer
matches the row in the database).









- Show quoted text -

Hi Earl. Thanks for responding.

I know my original question was vague; I wasn't sure what kind of
information was needed. I am using VS2005. I don't have an
underlying database. I am using a dataset to compile and store in-
session data from the datagrid. I didn't create a bindingsource; a
default one was created when I set the datasource of the datagrid. I
have not written any code to fire an update. The updates that are
occurring are happening automatically.

Can you tell me how to manually fire the update? I checked out
bindingsource on msdn but there is no method that explicitly states it
will update the datasource.

Thanks for your help!

 

[bidalah]

Just to make it clearer, here is the code where I beleive the trouble
lies:

Private Sub ImageEdit_SaveButton_Click(ByVal sender As
System.Object, ByVal e As System.EventArgs) Handles
ImageEdit_SaveButton.DoubleClick
Dim AllStringData_Dataview As DataView = New
DataView(VADP_DataSetMain.AllStringData)
Dim AllStringDataRow As DataRowView
Dim Changes(9) as string


For Each AllStringDataRow In AllStringData_Dataview
If AllStringDataRow.Row.RowState = DataRowState.Modified
Then

<i>' in the above two lines I am trolling for all rows in
my dataset that have been changed.
The only way to change them is manually ona datagrid that
is bound
to the dataset.</i>

(load values of this row into new dataset for "changed"
entries)
VADP_DataSetMain.ChangedStringData.AcceptChanges()

End If
Next
VADP_DataSetMain.AllStringData.AcceptChanges() ' this line
removes the rowstate notations in preparation for the next time
End Sub

Now my problem seems to be that the last row of the datagrid that gets
changed never shows up in the underlying dataset as changed. If I
alter 4 rows on the datagrid, only 3 lines in the underlying dataset
read modified. I could change ever cell on that last row, but without
actually clicking on a new row, it won't read as changed.

What I want is a way to force the final update of the datagrid to the
dataset (or the datagrid to the bindingsource?). Do you know how to
do this?

 

[Earl]

Maybe someone has a better answer than I, but I suggest that you monitor the
CurrentCellChanged event in the datagrid. Note that this event triggers
whenever the user clicks in the cell or when ANY changes are made. Also,
this event will fire on a delete.

 

[RobinS]

Hello all,

I have a Windows form datagrid which is bound to a datatable in a
dataset. I want changes that the user performs on the information in
the datagrid to be automatically reflected in the the underlying
datatable.

For the most part this is working. Then sometimes it does not, and I
can't figure out why. It seems that if you change a given datagrid
row, and then click on a different datagrid row, the change generally
gets recorded. If you change a row, and do not click on a different
row, the change is generally NOT recorded, no matter how many cells on
that datagrid row you altered. I don't understand why this is, and
why it is not completely predictable. It also creates a problem for
users who might simply make a change and forget the extra step of
clicking somewhere else.

What is the exact mechanism (event?) which causes the datasource of
the datagrid to be updated? Is there any way to force the datasource
to update itself? Any help would be appreciated.

Is it a DataGridView control?

Is it bound to a data source?

It probably triggers the Validate() event when it moves from one row to
another. If you are sitting in a row you have modified and the user closes
the screen or does something like that instead of moving to another row,
you should be triggering the EndEdit and Validate events yourself, like if
they click on <Save> or <Close> or something like that.

I know .Net 2.0; if you're using 1.1, I don't know how this applies, maybe
something about calling EndEdit on the BindingContext.

Robin S.

 

[RobinS]

What version of .Net are you using?

Robin S.