G
Guest
Hello,
This is the second part of my question. Forgive me if this post is too long
but I like to formulate a complete question.
I am currently building the DALC for our company application. When updating
a Dataset I thought it could be interesting to keep track of the rows that
were succesfully updated to the data source. I CAN achieve this, but it does
not look the slickest solution when working with MULTIPLE TABLES.
Here is what I do (quite simple):
1. Registering my adapter to handle the RowUpdated event:
myDataAdapter.RowUpdated +=new
OleDbRowUpdatedEventHandler(myDataAdapter_RowUpdated);
2. Handling the RowUpdated event to store the error message and skip the
AcceptChanges call:
private static void myDataAdapter_RowUpdated(object sender,
OleDbRowUpdatedEventArgs e)
{
if (e.Status == UpdateStatus.ErrorsOccurred)
{
e.Row.RowError = e.Errors.Message;
e.Status = UpdateStatus.SkipCurrentRow;
}
}
3. And last, simply updating the data set:
myDataAdapter.Update(myDataSet);
Since "SkipCurrentRow" will skip the call to DataRow.AcceptChanges(), the
resulting dataset (after it has been updated) will keep the RowState for
those rows where an error ocurred, the rest of the rows will have a
"Unchanged" state. This is all great!
(BTW, question on the side: Why do some examples appeal to calling
DataSet.AcceptChanges() after an Update .... isn't this done automatically by
the DataAdapter?)
Now, my problem with this solution is that my DAL is not using the
DataSet.GetChanges() method before calling DataAdapter.Update.
I know in
This is the second part of my question. Forgive me if this post is too long
but I like to formulate a complete question.
I am currently building the DALC for our company application. When updating
a Dataset I thought it could be interesting to keep track of the rows that
were succesfully updated to the data source. I CAN achieve this, but it does
not look the slickest solution when working with MULTIPLE TABLES.
Here is what I do (quite simple):
1. Registering my adapter to handle the RowUpdated event:
myDataAdapter.RowUpdated +=new
OleDbRowUpdatedEventHandler(myDataAdapter_RowUpdated);
2. Handling the RowUpdated event to store the error message and skip the
AcceptChanges call:
private static void myDataAdapter_RowUpdated(object sender,
OleDbRowUpdatedEventArgs e)
{
if (e.Status == UpdateStatus.ErrorsOccurred)
{
e.Row.RowError = e.Errors.Message;
e.Status = UpdateStatus.SkipCurrentRow;
}
}
3. And last, simply updating the data set:
myDataAdapter.Update(myDataSet);
Since "SkipCurrentRow" will skip the call to DataRow.AcceptChanges(), the
resulting dataset (after it has been updated) will keep the RowState for
those rows where an error ocurred, the rest of the rows will have a
"Unchanged" state. This is all great!
(BTW, question on the side: Why do some examples appeal to calling
DataSet.AcceptChanges() after an Update .... isn't this done automatically by
the DataAdapter?)
Now, my problem with this solution is that my DAL is not using the
DataSet.GetChanges() method before calling DataAdapter.Update.
I know in