Hello all,

I'm reviving the issue raised in this post because they're still relevant and I can't find an acceptable solution yet.

I am finding that catching database exceptions thrown during a delete operation is still an issue in the released version of Dynamic Data. Using the techniques discussed on the afore-mentioned thread, I am able to catch database exceptions thrown during insert and update operations and return appropriate messages to the UI by throwing a ValidationException. However, when it comes to delete operations, the exceptions aren't caught by the DynamicValidator, or anything thing at all. They simply cause a popup in IE (they are swallowed by Firefox 3.5) with the exception type being message being Sys.WebForms.PagerequestManagerServerErrorException, and the original error message. Someone please tell me how to get around this.

Hi I don't know if it was mentioned in the previous thread but you will also need to set the CausesValidation on the Delete button to be true this should allow the validation exceptions to be caught.

Yes, it was mentioned before, and I did do that, but it doesn't work still.

I've trawled this entire Dynamic Data forum for solutions but everyone keeps referring to David Ebbo's 2008 article. Whilst the information contained therein works for insert and update, delete seems to cause a difference in ASP.NET's behaviour (I'm using Linq2SQL, not ED). I have a ListDetails page on which I force an exception on the insert operation; it is caught, but doing the same for the delete operation doesn't work the same way. It seems that any exceptions, whether database, custom or otherwise, that occur during the delete operation by pass the entire infrastructure for catching exceptions.

The end I'm trying to achieve is to show a friendly error to the user when he performs what he thinks is a valid action - deleting a record. He shouldn't have to check first if there are associated records - the system should tell him so.

I know it's possible to accomplish this end by doing some checks before attempting the delete, but:

1. It is inefficient for me to do so. What if the table in question is parent to 10 others? I'll have to write 10 different Linq statements, which go as 10 different calls to the db. This will slow down all deletes for that table. I want to simply let the db do its job and tell me what's wrong. Then I can decide what to do.
2. I think it inelegant to have to handle deletes one way and insert/update another. Aren't you always looking for a more elegant solution? So am I.

In this post you say that there was a bug in the DynamicValidator, and that it was fixed in the ImprovedDynamicValidator.cs in the Dynamic Data Futures project. Might that bug be what's causing my problem?

clarenceg:

In this post you say that there was a bug in the DynamicValidator, and that it was fixed in the ImprovedDynamicValidator.cs in the Dynamic Data Futures project. Might that bug be what's causing my problem?

It could be I'll create a sample and test it tomorrow and get back to you and see if the problem persists, I'll also try with the Preview.

Update: It turns out that the browser I was using (Avant) was swallowing some of the errors and in some cases just behaving badly, even though it's supposed to be just a shell for IE. I've tried everything in IE proper and, following David's article, exceptions during delete are caught in the List page.

However, in the Listdetails page the problem still exists. Further, trying to set the CausesValidation property of the delete link buttons in the code-behind results in an error - "Setting CausesValidation on DataControlButtons is not supported.". The documentation says that the property is true by default but I've written code to spit out its value and it apparently is set to false by the framework. Further still, I added a template column to the gridview with my own delete link button, whose CausesValidation property was set to true. When I clicked on my button, a ValidationException I forced is caught and shown in the validation summary. However, database errors aren't shown.

Here is the code to my partial method in the datacontext

partial void DeletePoliceman(Policeman instance)
        {
          //throw new ValidationException("Can't delete policeman");
          try
          {
            ExecuteDynamicDelete(instance);
          }
          catch (Exception e)
          {
            throw new ValidationException("Can't delete policeman2", e);
          }

        }

If I uncomment the first line where an exception is unconditionally thrown, the message appears properly in the validation summary. However, I then commented that line, and depended on the second throw instance in the catch block to alert me to database errors. When I tried deleting a policeman record that had child records associated with it, the database error seemed to bypass the catch block, because I got the default error message - "The DELETE statement conflicted with the REFERENCE constraint", instead of ,u custom message I was expecting. So, my questions:

1. Can the CausesValidation property be set to true for the delete link buttons in the gridview (and the detailsview) of the ListDetails template page?
2. How can I trap database exceptions?
   

Hi Clarenceg, if you e-mail me using the 'contact' button I'll send a sample using Northwind for you to look at   

I've sorted all the pages including the ListDetails.aspx page to handle the DB errors

Hi Clarenceg, I’ve attached my demo for handling DB Errors, you will note that the following pages:

• Details.aspx
• List.aspx
• ListDetails.aspx

Have been modified (ListDetails.aspx the most) to allow delete validation to be passed through to the pages ValidationSummary mostly this is just setting the Delete button to CausesValidation=”true”; but on the ListDetails.aspx page you will need to setup all the GridView field templates (item, edit templates) to be able to set the validation on the Delete button and will not be able to use AutoGenerateXXXX buttons this applies to both the GridView and DetailsView.

Thanks for this Steve. It turns out that I have been doing the correct thing, mostly, all along. I had already figured out to use a custom link button on the listdetails page so that I could set CausesValidation to true. My problem was that I was using the wrong overload of the ValidationException constructor, like so:

I was using
 
      throw new ValidationException("error", e);

rather than something like

        throw new ValidationException("error: " + e.Message);

Apparently the former overload ignores the first argument and simply displays the message of the inner exception. Not seeing my custom message made think that the exception wasn't being caught by the catch statement in which the throw statement was placed. It was only when I saw that your site was working, with code very similar to mine, that I took a closer look at what I was doing. Thanks again.