RowState not updating

[Dale Harris]

I'm getting really strange behaviour where the data source RowState is not being updated to modified in some circumstances.

I place my controls on a form, bind them through a BindingSource control to a DataSet. If I don't do anything to the DataSet other than load data normally through TableAdapters everything works fine.

If I load a table(static data for ComboBox) in the DataSet manually; the DataSet now says it has changes. I call AcceptChanges() on the DataSet; this fixes the problem. Now, however, when my RowChange event is triggered, the data row's RowState never changes to Modified. If I remove the AcceptChanges() line when initialising the DataSet, the RowState property is updated as expected.

Can someone please help me.

 

[Cor Ligthert [MVP]]

Dale,

The acceptchanges is probably the most confusing method there is in dotNet, it is not accepting changes from a binded other class. That is done by a rowstatechange or by and endedit (endcurrentedit)

The acceptchanges set the rowstate to the status that all changes are done, in fact in a primary state to prevent that it is updated again.

I hope this gives an idea,

Cor
"Dale Harris" <[email protected]> schreef in bericht I'm getting really strange behaviour where the data source RowState is not being updated to modified in some circumstances.

I place my controls on a form, bind them through a BindingSource control to a DataSet. If I don't do anything to the DataSet other than load data normally through TableAdapters everything works fine.

If I load a table(static data for ComboBox) in the DataSet manually; the DataSet now says it has changes. I call AcceptChanges() on the DataSet; this fixes the problem. Now, however, when my RowChange event is triggered, the data row's RowState never changes to Modified. If I remove the AcceptChanges() line when initialising the DataSet, the RowState property is updated as expected.

Can someone please help me.

 

[Dale Harris]

That doesn't explain why the RowState hasn't been set to modified.

Dale.
Dale,

The acceptchanges is probably the most confusing method there is in dotNet, it is not accepting changes from a binded other class. That is done by a rowstatechange or by and endedit (endcurrentedit)

The acceptchanges set the rowstate to the status that all changes are done, in fact in a primary state to prevent that it is updated again.

I hope this gives an idea,

Cor

 

[Cor Ligthert [MVP]]

Dale,

It is probably set but you set it back with acceptchanges.

This accoording your text that there are changes.

Oherwise it can be that the data is still in the texboxes and not pushed down in the datatable. But that is nof confirm your first message.


Cor
"Dale Harris" <[email protected]> schreef in bericht That doesn't explain why the RowState hasn't been set to modified.

Dale.
Dale,

The acceptchanges is probably the most confusing method there is in dotNet, it is not accepting changes from a binded other class. That is done by a rowstatechange or by and endedit (endcurrentedit)

The acceptchanges set the rowstate to the status that all changes are done, in fact in a primary state to prevent that it is updated again.

I hope this gives an idea,

Cor

 

[Dale Harris]

When I inspect the RowChanged event, the row data has changed by the control, BUT the RowState remains as unchanged, NOT modified, as one would expect.

What I have observed is that by calling AcceptChanges() when initialising the DataSet BEFORE opening the form causes the above problem.
Dale,

It is probably set but you set it back with acceptchanges.

This accoording your text that there are changes.

Oherwise it can be that the data is still in the texboxes and not pushed down in the datatable. But that is nof confirm your first message.


Cor

 

[Cor Ligthert [MVP]]

Dale,

In these situations are in this newsgroup the underlying piece of code showed. We cannot see what you write.

Cor

"Dale Harris" <[email protected]> schreef in bericht When I inspect the RowChanged event, the row data has changed by the control, BUT the RowState remains as unchanged, NOT modified, as one would expect.

What I have observed is that by calling AcceptChanges() when initialising the DataSet BEFORE opening the form causes the above problem.
Dale,

It is probably set but you set it back with acceptchanges.

This accoording your text that there are changes.

Oherwise it can be that the data is still in the texboxes and not pushed down in the datatable. But that is nof confirm your first message.


Cor

 

[Dwight]

In order for the binding source to update the rowstate of the dataset,
you must call the .endedit method of the binding source. If you then
check the rowstate, it will accurately reflect the status of the row.
Keep in mind that this does not update the underlying database, just
the dataset. You need to call the .update method of the table adapter
to update the underlying database.

ie
bindingSource.EndEdit() 'This sends the updates to the dataset
messagebox.show(Ctype(bindingSource.Current,DataRowView).Row.RowState
'This gives you the rowstate of the current row of the bindingsource
tableAdapter.Update(dataSource.datatable) 'This pushes the updates down
to the underlying database

Dwight

 

[Dwight]

In order for the binding source to update the rowstate of the dataset,
you must call the .endedit method of the binding source. If you then
check the rowstate, it will accurately reflect the status of the row.
Keep in mind that this does not update the underlying database, just
the dataset. You need to call the .update method of the table adapter
to update the underlying database.

ie
bindingSource.EndEdit() 'This sends the updates to the dataset
messagebox.show(Ctype(bindingSource.Current,DataRowView).Row.RowState
'This gives you the rowstate of the current row of the bindingsource
tableAdapter.Update(dataSource.datatable) 'This pushes the updates down
to the underlying database

Dwight

 

[Cor Ligthert [MVP]]

Dwicht,

I am glad you tell this to me, however this is not in the case as the
dataset."haschanges" already as trie as Dale, wrote. Otherwise I would have
given an answer like yours although that in version 2003 the endedit is not
really working well and you need the endcurrentedit.

Cor

 

[Cor Ligthert [MVP]]

Dale,

Have you read my first reply about what "acceptchanges" does?

Cor

 

[Dale Harris]

Col,

Yes, I have. It's hard for me to give you a sample of what I'm doing
because it's all wrapped around Infragistics controls. When using the
Infragistics controls and have them bound to a BindingSource, the
DataSet.HasChanges() return True. I don't understand why, but that's what
happens as I modify fields on the screen. I really liked that behaviour as
there was a way to test if changes have been made to the row, otherwise
you're in the dark unless you test each field individually (time consuming).
This behaviour stopped as soon as I loaded a table manually and perform an
AcceptChanges() on the DataTable, DataSet, or on each DataRow individually.
From reading the help file on BindingSource.CurrentItemChanged, I was hoping
that event would have done the trick for me.

Why doesn't the BindingSource have some sort of event on a column
change, rather than going all the way back to the underlying DataTable in
the DataSet? If the underlying DataRow has changed (from what I can tell it
does change), shouldn't there be a flag on the Row to indicate if a change
has been made? If no changes have been made, why would you want to call
EndEdit() to possibly create more overhead when saving data?

Sorry about the probing questions, but my get feeling says that there
are a lot of short comings to data binding.

Dale.

 

[Cor Ligthert [MVP]]

Dale,

If you read my reply than you probably did not understand it, than I take a
simpler approach.

The acceptchanges does not accept the changes. It is meant to set the
hasChanges consequently off.

Cor

 

[TonyAlderman]

I am having the same problem.

I load a dataset with data, and call AcceptChanges() to set all of the
added records to "unchanged". (Does everyone understand this? This is
before databinding!)

I then set up databinding and change a value. Everything seems to be
working at this point. The changed value is saved to the dataset. But
on closer inspection, the rowstate is left as "unchanged".

I should add that most of the time this works fine and the rowstate is
changed to "modified", but other times I can see the value in my
dataset change from a NULL to the value I typed in, but the rowstate
remains "unchanged".

As the original poster mentioned, this behavior happens when
AcceptChanges() is called on the dataset before ever setting up
databinding. But at no time am I calling AcceptChanges() after I set up
databinding or change the value.

Thanks,
Tony

 

[Cor Ligthert [MVP]]

Tony,

Changing of the rowstate (data) is done at a rowchange or by calling the
methods EndCurrentEdit in version 2003 or EndEdit in 2005.

Cor