Hi Sam,

First I agree with your other post that a constraint needs to be in the database for a multitude of reasons in protecting your data. But since you are a defensive programmer it would be better not to leave your program to catching a database constraint as your application method.

When you call a save either directly to the business object or via a form save method you would get a mmSaveDataResult object. That object may be an exception due to the constraint. In my perspective while catching a exception is effective I don't think it should be used as a standard method of testing your save. I personally would implement a test of the data in order to make every effort to reduce the amount of times it would need to be caught via an exception.

The mmSaveDataResult will return either RulesBroken, RulesPassed, RuleWarnings, SaveCanceled, or an Exception. The exception is what you get when there is a constraint error. It is already caught for you, but is a Try Catch none the same.

I hope that helps. Based on your reply to Randy, I think you are on the right track. IMHO anyway.
Tim

>Hi Tim,
>
>Thanks for your reply. Are you saying that in order to display a meaningful exception message to the user in a graceful way that I will need to add Try Catch code somewhere? Where?
>
>Sam
>
>>I would agree with Randy here in that only catching and reporting database errors is a bit of an ineffiecient way to do this. When you wrap your mm Save in a Try Catch you will catch an error which will give you a string result of your database issue. It would be better and more efficient to call the child business object to retrieve all child records for that parent and see if there are any rows returned. This might even be faster than dealing with a caught exception.
>>
>>I would still leave my database constraint in place however, so I would think you need both.
>>Just my thoughts also.
>>Tim