[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

dataset acceptchanges vs bindingsource endedit

Posted on 2006-06-23
7
Medium Priority
?
8,661 Views
Last Modified: 2012-08-13
are they the same?
0
Comment
Question by:newyuppie
  • 3
  • 3
7 Comments
 
LVL 17

Expert Comment

by:ZeonFlash
ID: 16974060
Technically, no.  When you call AcceptChanges, it invokes EndEdit automatically.  This might clear things up:  http://msdn2.microsoft.com/en-us/library/system.data.datarow.acceptchanges.aspx
0
 
LVL 34

Expert Comment

by:Sancler
ID: 16974504
No, they're not the same and - with apologies to ZeonFlash ;-) - the difference is a bit more than technical.  

When a user edits data in a bound control those edits are not immediately (e.g. with each keystroke) passed to the datasource (ie the datatable): that only happens when there is notification that the editing has ended.  Soemtimes this happens implicitly - e.g. if the user moves to a different row/record - but if not the notification has to be given explicitly with .EndEdit.

When that notification has been given the edited data is passed to the datatable but (a) a version of the data in its unedited state is also retained by the datatable and (b) the .RowState flag is set to indicate that the row has been changed.  What .AcceptChanges does is remove earlier versions of all rows from the datatable (or from all datatables in the dataset) and reset all the .RowState flags.

The implications of this are important so far as updating the database is concerned.  TableAdapters (and DataAdapters) work, so far as their .Update commands are concerned, by checking the .RowState flags.  If .AcceptChanges has been called - resetting the flags - before .Update is called the adapter will find no flags indicating that any changes need to be made.  So it will do nothing.  The database will not be updated.

Roger
0
 
LVL 13

Author Comment

by:newyuppie
ID: 16975842
roger thanks for this clarification. maybe you can instruct me on which cases should one call .acceptchanges, and on which cases .endedit? seems like if i need to update a database with a tableadapter i should not call .acceptchanges. maybe this call should only be used if you create the dataset programatically and dont need to persist that to a database.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
LVL 34

Accepted Solution

by:
Sancler earned 2000 total points
ID: 16976139
As a rule of thumb .AcceptChanges should really only be necessary after an .Update has been called.  Before VB.NET 2005, Framework 2, this had to be done explicitly to ensure that the application's local datatable remained "in synch" with the equivalent database table, each regarding the same records as currently valid.  But in VB.NET 2005 DataAdapters (hence TableAdapters) have a new property which can be set to call .AcceptChanges automatically when an .Update is performed.  See this

http://msdn2.microsoft.com/en-us/library/system.data.common.dataadapter.acceptchangesduringupdate.aspx

and, for an explanation of the order in which things happen on an .Update, see this

http://msdn2.microsoft.com/en-us/library/system.data.common.dataadapter.update.aspx

about half way down the page.  Although there will no doubt be special cases in which the programmer will want to "custom-control" the calling of .AcceptChanges, I think for most practical purposes the sensible approach in VB.NET 2005 is to ensure that .AcceptChangesDuringUpdate is set to True and then forget about it.

If you create/fill a datatable/dataset programmatically then you can make your own rules about when to call .AcceptChanges.  As there is no need to keep the data "in synch" with anything, then there is perhaps no need to call it at all.  On the other hand, it does "tidy things up" a bit.  So the choice is yours.

As I said before, .EndEdit is often called implicitly (or automatically) when a user navigates to a new row/record: e.g. by clicking on a different row in a DataGridView or using a forward or back button on a BindingNavigator.  The one time it can be essential to call it explicitly is when a user can move directly from editing a record to a "Save" button.  It depends on precisely which controls are being used to edit the records but it is possible, in that scenario, that (because there has been no movement to a different record) the edit on the current record will not have got back to the datatable before the .Update is actioned.  For that reason, it is sensible to precede any .Update call with an .EndEdit on the BindingSource (or .EndCurrentEdit on a CurrencyManager or BindingManagerBase).  It does no harm if it is not in fact needed, but it avoids the possibility of the latest change not reaching the database.

Again, there may be scenarios where the programmer wants more detailed control (or to make assurance doubly sure) but as a rule of thumb that is the only place - just before an .Update - that I would bother about it.  The one possible exception to that rather blase approach is explained here

http://msdn2.microsoft.com/en-us/library/system.windows.forms.bindingsource.addnew.aspx

at the para. numbered 3 in the Remarks.  But that is quite a special case - as you will see if you follow the link to IEditableObject interface - and, for a "rule of thumb", I reckon it can be ignored ;-)

Roger
0
 
LVL 13

Author Comment

by:newyuppie
ID: 16980179
roger, thank you so much for your detailed and most informative answer.
i have no questions, everything is perfectly explained and i understand it.
as a failry new ADO.NET user in vb2005, i had a hell of a time trying to understand all the events, methods, things about data binding. i have found your links very very useful, definitely what i needed.
am raising the points to 500

thanks again for the answer
0
 
LVL 13

Author Comment

by:newyuppie
ID: 16980181
raising points
0
 
LVL 34

Expert Comment

by:Sancler
ID: 16980267
Thanks for the points and your most gracious comments.

Roger
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This tutorial demonstrates one way to create an application that runs without any Forms but still has a GUI presence via an Icon in the System Tray. The magic lies in Inheriting from the ApplicationContext Class and passing that to Application.Ru…
Creating an analog clock UserControl seems fairly straight forward.  It is, after all, essentially just a circle with several lines in it!  Two common approaches for rendering an analog clock typically involve either manually calculating points with…
Integration Management Part 2
Loops Section Overview
Suggested Courses
Course of the Month19 days, 13 hours left to enroll

873 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question