Hi Bonnie,

I have read your blog several times and I read a chapter in my C# book on anonymous delegates. I still can't get my mind wrapped around what you are doing there. I just need to read it again and again until I get it. Thank you for pointing me in the right direction though.

As far as logging error; at this point this is not what I am doing; although I am sure it will be necessary at some point.

What I am trying to do is to deal with issues caused by user inadvertently leaving entry in the field that requires entry blank or entering a duplicate value. And in this case all I want is that the DAL (via call to SP) to return back to UI the error message from stored procedure (which I am thinking about changing into easily readable for a user). And then, without Un-Doing the entry let the user make the changes him/herself. That is, I don't want the DAL to Un-Do but only to return the "error" message to the UI.

>Hi Dmitry,
>
>>Now, after re-reading the blog III again, I see how you are handling the error. Very nice. I am not sure why you used the name Start() though. To me, it seems more like .End() <g> since you call it at the end of methods.
>
>Look a little closer. It's not called after methods. The stuff you write before it in your DataAccess sub-classes are anonymous delegates. And, if you recall from reading my blog, the names of the methods and delegates were changed from reality because I didn't want to get in trouble with the company for posting code (even though it's not exactly the same and simplified greatly from actual production code).
>
>First, in your sub-classes, you're stating what operations you want to be performed with the DoIt delegate (called the Operation delegate in reality) and then what what you want to do if there's an error and you need to un-do (rollback changes and stuff) from that error (UndoIt delegate in blog example, UndoOperation in reality).
>
>After you've specified what you want to have done, then you start the whole process up with the call to the Start() method (BeginOperation() in reality). The Start() method is in your base class and simply runs the code in the DoIt delegate within a try, and executes the stuff in the UndoIt delegate
>in the catch.
>
>Now, as far as handling errors, in real-life I have written the exception error messages, along with a stack-trace, to the computer's EventLog (this would be on the server) and passed a more generic message back to the front-end, something to possibly indicate why the Save operation had problems, but nothing really technical ... the technical info gets sent to the EventLog. This can be viewed by the user when calling TechSupport if needed, or an app can be written against info in the EventLog to maybe automate the process (something I have NOT done).
>
>If you need info on writing to the EventLog, take a look at System.Diagnostics.EventLog. It's really pretty easy, as long as you have permissions set up correctly.
>
>~~Bonnie
>
>
>
>
>>Hi Bonnie,
>>
>>Now, after re-reading the blog III again, I see how you are handling the error. Very nice. I am not sure why you used the name Start() though. To me, it seems more like .End() <g> since you call it at the end of methods. But it gives me now something to work on. By the way, in your real application did you return actual error to the UI? My customers will be very confused by these types of messages. I am thinking, therefore, to create a table translating the error message into less confusing and more readable English sentence. I will probably (just thinking out loud) put an ID into the name of a constraint to use as a key to find a corresponding entry in a table. I have not thought out how I will do it and if this table will be a real table or some kind of a text file.
>>
>>
>>>Hi Dmitry,
>>>
>>>Thanks for referring to me as "famous". <g>
>>>
>>>So, if you used my example totally as your DAL, then you probably had to tweak it a bit (for lurkers, I believe Dmitry is referring to Part III of my DataAccess series: http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-iii.html).
>>>
>>>I noticed in the Start() method that it handles exceptions by this statement:
>>>

this.AddToErrorMessage(e);

>>>And of course there is no AddToErrorMessage() method in my example. There is, however, an ErrorMessage property in the original BBDataAccess class shown in Part II: http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-ii.html
>>>
>>>If your Start() method returns a false, you should be able to access the ErrorMessage property and do something with it, like return it to your UI.
>>>
>>>Does this help?
>>>
>>>~~Bonnie
>>>
>>>
>>>>Hi,
>>>>
>>>>How do you deal with cases when database update (SQL Server) fails (e.g. constraints)? Here is a code from the DAL class that updates the database (this is not my code; I borrowed it from a blog of a famous person here <g>):
>>>>
>>>>

>>>>       protected void SaveTable(DataTable Table, string SaveProc)    
>>>>        {        
>>>>            foreach (DataRow row in Table.Rows)
>>>>            {            
>>>>                this.SetAllParameters(row);
>>>>                this.ExecuteCommand(SaveProc);
>>>>            }    
>>>>        }
>>>>
>>>>// The problem occurs in method ExecuteCommand.  And the ExecuteCommand method looks like this:
>>>>//  simplified
>>>>protected void ExecuteCommand(string StoredProcName)    
>>>>        {        
>>>>
>>>>            try         
>>>>            {             
>>>>                this.oCommand.ExecuteNonQuery();
>>>>            }        
>>>>            catch (Exception ex)
>>>>            {
>>>>                // !! This is where I get the error that Breaks the code.  
>>>>                throw ex;
>>>>            }        
>>>>         }
>>>>
>>>>

>>>>
>>>>What I would like is to be able to return the error message back to the UI layer to be displayed.
>>>>
>>>>TIA for any suggestions.