Thanks.

>Thierry,
>
>>#1 I think this is also part of a more general problem. If a user is editing a Date field in the mmDataGrid, but he enters an improperly formatted date then the system fails... this also happens in the jump start web application of the documentation if I enter characters where an integer was expected. How should I deal with this?
>
>From an end-user's perspective, the system shouldn't allow the user to enter data in an invalid format. This is really one of the places where Microsoft fell down on the job--the lack of easy-to-implement formatting of input data. This is one of the big reasons why companies like Infragistics, ComponentOne and Developer's Express have done so well...The out-of-the-box .NET Web Forms DataGrid allows you to specify a "Data formatting expression" to specify how a value is displayed, but it doesn't enforce invalid data entry! This is one of the reasons why we are in the process of integrating with these Third Party UI components. Microsoft is addressing this in Whidbey, but that won't be available for another year!
>
>>#2 I still don't understand how to deal with a failed trigger error. I don't want to check for that in the business rules object, I let the stored procedures deal with that. But should not the business object handle the exception?
>
>That does relieve a burden on the developer, but it doesn't create the most performant system. If you have your business objects catch these sort of errors before they hit the database, it produces a lighter burden on your database server, when considering issues of scalability. To make this easier for developers we are also in the process adding functionality to MM .NET for automatically generating XML business rules and associated business rule classes.
>
>MM .NET business objects have a HandleException method that checks for exceptions that are raised when saving data. One of the exceptions we are currently handling is the ConcurrencyException. We are adding more logic to this method to handle other exceptions such as failed triggers (by displaying them as broken rules). If you want an easy, sooner-than-later solution, you can simply override the HandleException method and handle exceptions in any way you see fit. For example, you could add certain exception messages to the broken business rules rather than re-throwing the exception as is currently done.
>
>Regards,