>>>>I'm working with the MM desktop maintenance template. By default the framework wants to validate everything in both the List and Properties tabs. This makes sense if the grid view in the List tab were editable. However, the spec for the project my company is working on is that the List view is read-only. Therefore, when I click the mmSaveButton in the Properties view, I want ONLY the fields in the the Properties view to be validated and updated.
>>>>
>>>>From what I understand, the only way to do this is to have two binding sources. But I'm not sure how to accomplish this. When I go to the BindingSource property of any of my mmTextBox controls in the Properties view, the ellipses forces you to pick the name of an existing business object. This is a problem obviously because the MM framework assumes that if the name of the binding source on the list tab and the properties tab are the same, that a single source should be used to bind the entire form.
>>>>
>>>>How do I get around this? Do I have to make a duplicate business object? Seems like that could be a maintenance nightmare. Does anyone have any other suggestions?
>>>>
>>>>Thanks.
>>>
>>>What is happening to cause the validation? What results are you getting that you don't want to happen? In other words, if you have a list of records and then you have a property page (much like the jump start) and you edit a record on the property page, what is happening that you don't want to happen?
>>>
>>>The binding source options are based upon the business object instances that are registered with the page. This is an instance of a business object and no need to create multiple business object classes. You are right, that would be a maintenance nightmare. A bit more info and I will try to help.
>>>Tim
>>I'm going to take a guess that you are running into something I ran into. The business rules are set up to check the entire table when you save. You can modify the business rules object to only validated rows that do not have a state of deleted or unchanged. It won't limit the columns that get validated but it will limit the rows that get checked.
>>If you really don't want to check all the columns, while I think that's a bad idea, you could possibly create a separate datatable in your existing business object that has only the columns that you want. You would probably have to check for that table name in your rules object to turn off rule checking by column. If I were doing that, though, I would limit the rules in the business object to just the rules that apply to every table. If you have some additional rules, you could enforce those through a HookPreSave method.
>>I hope this helps.
>
>Hi Linda,
>You mention you ran into this. Would this be because of existing data that didn't meet the rules defined? Depending on the situation I would think the rules would then need to be enforced in order to bring the data in line with the rules as they are discovered. Or more prefereably some routine created and run where the data is corrected. Did you find something happening where validating data you didn't change caused a problem? Just curious. I didn't see where the original poster added any more info on the subject.
>Tim

Tim,
I absolutely agree that you would normally want the rules to be enforced to bring the data in line. However, when there are many rows of data, besides the performance issues, it's not helpful for the user to get an error for a row he/she is not seeing nor do I want that user to have to wait for all those validations. This was mostly happening in screens where either the user was editing in a grid or using a grid to navigate. It's not a big deal if there are only 5 rows in the grid. It's a problem if there are 30 rows and the one with the error is not showing on the grid.

I am handling those data issues as I go along. We're still in test mode, so I continually update the SQL procs that import the data so, when we get ready for final conversion before going live, I will, with any luck, have all those issues resolved. While I'm testing, it's just plain irritating to have to deal with all the data issues for 30 rows when I'm just trying to test a data entry screen and one error is sufficient to tell me what I need to know.

Good advice, as always. Linda