AcceptChanges and Updates once more

So the following question was posted to a forum I frequent and it serves a good point of illustration:

"I wont to clear all the data from tables in the database. I have studentiDataset, and i tried this code:
Form2.StudentiDataSet.Clear()
Form2.StudentiDataSet.AcceptChanges()
I also tried to add after this code tableadapter update method for all tables but it didn't work.
How can i doo that?
Thanks!"

Remember the basic behavior of Adapters. When the Update method is called, it loops through each row and checks the RowState. Depending on what it finds, a different action is taken. 

• The row's RowState is Deleted:
  • The adapter looks for a valid Delete command and executes it.
  • It calls AcceptChanges on the row unless AcceptChangesOnUpdate is set to false
  • If no Delete command is present, it throws an exception
• The row's RowState is Modified:
  • The adapter looks for a valid Update command and executes it
  • It calls AcceptChanges on the row unless AcceptChangesOnUpdate is set to false
  • If no Update command is present, it throws an exception
• The row's RowState is Added:
  • The adapter looks for a valid Insert command and executes it
  • It calls AcceptChanges on the row unless AcceptChangesOnUpdate is set to false
  • If not Insert command is present, it throws an exception
• The row's RowState is Unchanged:
  • Nothing happens

Ok pay close attent to the last of these choices.  So what happens when you call AcceptChanges?  Well, you can call it on a Row, a DataTable or a DataSet.  Whenever you call it on a DataRow, the RowState goes back to Unchanged.  When you do it to a DataTable, all the rows in the Table are set back to Unchanged. And when done on a DataSet, it sets all the rows in all the tables back to Unchanged.

So what happens if you call Update after AcceptChanges? Unless something is changed in between them, it has a similar effect to calling Thread.Sleep(10); because it basically does nothing.

Now, specifically to this question. AcceptChanges is ensuring that none of the deleted rows are every sent back to the database.  However unless you had a specific reason (like a transaction) to do so, then this is probably one of the least efficient ways to delete all the rows for a table.  "TRUNCATE TABLE" is the most efficient option and is appropriate unless you need the changes logged.  Otherwise, a single "DELETE FROM Whatever" should work.  Imagine having 10,000 rows.  Truncate or delete do it in one action as opposed to 10,000 of them so unless there's a compelling reason to do otherwise, this should be avoided.