R
Ramon de Klein
I am using ADO.NET datasets to transfer information
between my client and business logic. When I fill the
dataset and some dataset contraint is triggered, then the
FillError event is triggered, that can be handled. My
database contains some constraints that can be triggered
when propagating the dataset changes back to the database.
I use the SqlDataAdapter.Update to send this information
to the database. Unfortunately, there is no UpdateError
event that can be handled. I would have liked an event for
these errors that specify the datatable, row and
SqlException (a bit like the FillErrorEventArgs).
I have created a workaround, but this looks horrible. I
call the dataadapter's Update method and catch the
SqlException. Then I will iterate through the dataset and
find the first non-Unchanged row. That should have
been the row that has failed. Things become even more
complex when relational datasets are being updated,
because they are updated in a different order. When a
UpdateError event would have existed, then this would have
been much more easy.
Now I investigate the SqlException by checking the message
number and parsing the message string. I don't like this
behaviour, but I don't think there is a better way. Anyone
have a suggestion?
between my client and business logic. When I fill the
dataset and some dataset contraint is triggered, then the
FillError event is triggered, that can be handled. My
database contains some constraints that can be triggered
when propagating the dataset changes back to the database.
I use the SqlDataAdapter.Update to send this information
to the database. Unfortunately, there is no UpdateError
event that can be handled. I would have liked an event for
these errors that specify the datatable, row and
SqlException (a bit like the FillErrorEventArgs).
I have created a workaround, but this looks horrible. I
call the dataadapter's Update method and catch the
SqlException. Then I will iterate through the dataset and
find the first non-Unchanged row. That should have
been the row that has failed. Things become even more
complex when relational datasets are being updated,
because they are updated in a different order. When a
UpdateError event would have existed, then this would have
been much more easy.
Now I investigate the SqlException by checking the message
number and parsing the message string. I don't like this
behaviour, but I don't think there is a better way. Anyone
have a suggestion?