none
How can I tell if changes to a table are pending? [i.e., determining "state" of a datatable] RRS feed

  • Question

  • This is one of those things that should be brain-dead simple, but is currently eluding my efforts to find exactly which property or event would give me this information.

     

    In a nutshell, I have used the designer to map an existing database to various objects (bindingsources, tableadapters, etc.)  I've done the "drag-n-drop" thing of pulling a "table" from the datasource onto a form, and it has dutifully created the fields to be editing and a "navigator" for forward/back/new/delete/save functions.  All that is nifty, but...

     

    the user makes "a ton of changes" [where "ton" is defined as "more than one"], and for whatever reason clicks the CLOSE button on the form thinking his changes all "took" [after all, during editing, he could see that moving forward and backwards past items he has edited shows those changes are "there"]  Imagine the tongue lashing I get when he finds out he forgot to click the SAVE button in the little navigator form.

     

    [ok, that was slightly hypothetical] my testing rather quickly revealed that "by default" you get a very pretty and seemingly useful form when using the drag-n-drop method of creating it, however critical little details like informing the user that those changes he has made will get wiped out if he proceeds to exit without saving have been left out.

     

    So.... I go to add this functionality -- easy enough to add in a test during the "form_closing" event to see if any changes have been made, and if so inform the user [giving them the possibility to save, discard, or resume editing without actually closing the form] however I cannot find the "changes have been made to the dataset but not committed back to the underlying data store" property of the bindingsource, underlying table, or bindingnavigator.

     

    So... again, I add more code that should have been there to begin with -- I added an "is the dataset/table 'dirty'? flag and I see I can trap on the "new item added" event [obvious "dirty" case] and can certainly clear the flag after the "save" event, but what about changes within a given (existing) row?  both the "currentchanged" and "currentitemchanged" events fire if the user simply navigates from one record to the next without making any actual changes -- not good as now it implies a change was made when in fact nothing changed.

     

    I've even tried using a "dataVIEW" object and setting the "rowstatefilter" to [added+modified], and that almost works as well -- it turns out if you don't actually navigate away from the record, it isn't yet committed even to the in-memory table, and thus the count is zero.

     

    So I'm up to three levels of "kludgy-ness" and it still isn't working -- I figure I must have overlooked a [possibly oddly worded?] property that would identify this "state" right off....

     

    Friday, October 26, 2007 2:24 AM

Answers

  • Well, after a night of rest and a joyus romp through "try EVERYTHING, damnit!", I found that the listchanged event has, as part of the event properties, an indication of just what caused the list to "change", so now I have:

     

    Code Block

    Private Sub MyBindingSource_ListChanged(ByVal sender As Object, _

                                            ByVal e As _

                                              System.ComponentModel.ListChangedEventArgs) _

                Handles MyBindingSource.ListChanged

     

        Select Case e.ListChangedType

            Case System.ComponentModel.ListChangedType.ItemAdded, _

                 System.ComponentModel.ListChangedType.ItemChanged

                changesmade = True

            Case System.ComponentModel.ListChangedType.Reset

                changesmade = False

        End Select

    End Sub

     

     

    I'm not 100% certain that the "reset" test is needed, but in coming up with this I saw that the "reset" case occurs three times during the form load process, so clearing on reset seems reasonable.  (if there is ever a real-life situation that causes the "reset" to occur and in turn cause the app to discard some changes, I'll blame it on the fact that I cannot get whatever psychodelic drugs the microsoft developers were on when they came up with this *** in the first place...)

     

     

    Friday, October 26, 2007 6:13 PM

All replies

  • Tom,

     

    I am new to all of this as well but have just worked my way through the exact scenario that you are faced with.  I am using the CellValueChanged event to trigger the "dirty" switch.  HTH.

    Friday, October 26, 2007 5:54 PM
  • Well, after a night of rest and a joyus romp through "try EVERYTHING, damnit!", I found that the listchanged event has, as part of the event properties, an indication of just what caused the list to "change", so now I have:

     

    Code Block

    Private Sub MyBindingSource_ListChanged(ByVal sender As Object, _

                                            ByVal e As _

                                              System.ComponentModel.ListChangedEventArgs) _

                Handles MyBindingSource.ListChanged

     

        Select Case e.ListChangedType

            Case System.ComponentModel.ListChangedType.ItemAdded, _

                 System.ComponentModel.ListChangedType.ItemChanged

                changesmade = True

            Case System.ComponentModel.ListChangedType.Reset

                changesmade = False

        End Select

    End Sub

     

     

    I'm not 100% certain that the "reset" test is needed, but in coming up with this I saw that the "reset" case occurs three times during the form load process, so clearing on reset seems reasonable.  (if there is ever a real-life situation that causes the "reset" to occur and in turn cause the app to discard some changes, I'll blame it on the fact that I cannot get whatever psychodelic drugs the microsoft developers were on when they came up with this *** in the first place...)

     

     

    Friday, October 26, 2007 6:13 PM
  • Much cleaner than setting up the multiple datatable events.  Thanks

     

    Friday, October 26, 2007 7:00 PM