DataSet.DataTable Has Changed?

JaedenRuiner

Well-known member
Joined
Aug 13, 2007
Messages
340
Programming Experience
10+
Again here I am, looking for help. :D

Given a Typed DataSet with Typed DataTables, etc. I've got multiple binding sources and all the wonderful hoopla on my forms, and through them all I can manipulate everything exactly as I want it. When they which the table selector in my combobox, it requests from my wrapper class (that controls all the DataSet/DataTable/TableAdapters and more) to switch the active table.

Which it switches the active table it needs to do two things:

Determine if the table is a Typed Table (this it already does) and either using a generic TableAdapter (with an added table to the dataset.Tables() collection) fills that table, or uses the typed TableAdapter and fills the Typed DataTable.

HOWEVER, before it does this "refresh" of the active table, I would like (as appropriate) to make sure the Current Table has not changed in any way. (ie records added, deleted, or edited), and if they have, pose the question to the User to Save Changes or Delete them.

Now I have a Save Button on my form set up to manually effect this "Saving of DataSet to The actual DataBase" (ie commit changes), but sometimes, as we all know, users may forget to do that and I need to pose the question "Hey you changed something, Keep it or Discard?"

1. How do I determine if a DataSet.Table(#) was Changed?
(I would prefer using the UnTyped Tables() for the default DataTable(). Is there a boolean or something that reflects changes were made?)

Secondly, I have noticed a few things with the DataSet(Typed) that makes me question which is preferable or appropriate to use.

  • DataTable.AcceptChanges() / DataTable.RejectChanges()
  • TableAdapter.Update(DataTable)

Granted, I know that the SqlDataAdapter (which is how the Typed TableAdapter operates on the Typed DataTable) utilizes the Select/Delete/Update/Insert SqlCommands, and thus if I am to create a user table with a SQL command and add it to the DataSet.Tables() collection, I would need to write those commands if I wanted to use a SqlDataAdapter() on the unTyped DataTable. But for the Typed DataTables()/TableAdapter is it:
  • Preferable to use the TableAdapter.Update(DataTable) method on changes and the TableAdapter.Insert(<params>) on Additions?
  • If using a DGV to insert the data into a dataset, and the user adds or updates a row within the DGV can I just call DataTable.AcceptChanges() and the same effect takes place?

Thanks

(Also, I do know that some of my tables use StoredProcedures to Handle Inserts and Updates, so they will NOT be using DGVs to Add New Rows, I'm just trying to get a handle on which is the preferred way to commit changes to a Database from a DataSet - TableAdapter or DataTable.AcceptChanges())
 
(Also, I do know that some of my tables use StoredProcedures to Handle Inserts and Updates, so they will NOT be using DGVs to Add New Rows, I'm just trying to get a handle on which is the preferred way to commit changes to a Database from a DataSet - TableAdapter or DataTable.AcceptChanges())


DT.AcceptChanges() does not and cannot persist data to a database. Further it will remove all evidence of which rows have changed by (funnily enough) accepting all the changes! This means a TA wont find any rows that need updating.

TA.Update() automatically does an AcceptChanges when it is done
 
Bloody hell you like making things complicated don't you? For the sake of recycling a datagridview?

Now I have a Save Button on my form set up to manually effect this "Saving of DataSet to The actual DataBase" (ie commit changes), but sometimes, as we all know, users may forget to do that and I need to pose the question "Hey you changed something, Keep it or Discard?"
If there is no possibility that any table in the DataSet other than ont one in question has been edited, then you can call DataSet.HasChanges()

If you have 10 tables and an autonomous proces edits table 1 while the user edits table 9, DS.HasChanges() WILL NOT help you determine if the user has made edits, because it might return true as a result to edits on table 1. only use DS.HasChanges if you are working solely with one table in the dataset




But for the Typed DataTables()/TableAdapter is it:
  • Preferable to use the TableAdapter.Update(DataTable) method on changes and the TableAdapter.Insert(<params>) on Additions?

  • I foresee no reason why. I normally jsut add my rows to the DT, edit others, delete a few more and then Update() the whole lot.
    If you Insert() then the row wont show locally unless you re-download it from the database. Which has always struck me as an arse-about-face way of doing things

    [*]If using a DGV to insert the data into a dataset, and the user adds or updates a row within the DGV can I just call DataTable.AcceptChanges() and the same effect takes place?
    You insert data into a DT, not a DS

    Calling AcceptChanges accepts the changes. The New row becomes Unmodified in state, and Original in version, meaning it looks like it was downloaded from a db, but it wasnt, so it will NEVER be persisted back there unless you do it manually, or call SetXXX to revert the row state to what it should be for Update

    You make this way complicated. Just perform all your ops on a DT as though it was a database, and then use Update() to save your changes. Stop mixing methods! ;)
 
Back
Top