Brian,

>I have a Business Object that I populate on the fly with new records. I have its AutoClearRules property set to False. During the process of populating this Business object I check for a condition that may invalidate the row. If I find the condition then I add a broken rule to the rulesprovider like so.
>

>Dim dsEP As DataSet = Me.ExportDetailBO.GetCurrentDataSet
>  mmerrrorprov = New OakLeaf.MM.Main.Business.mmErrorProviderArgs(dsEP, Me.ExportDetailBO.TableName, _(Me.ExportDetailBO.GetRowCount - 1), "DLN", "has an unresolved Void Request. ", False)
>
> Me.ExportDetailBO.Rules.AddErrorProviderBrokenRule(mmerrrorprov)
>

>Lets call this step 1.
>At this point everything is fine the rule shows up in the error provider and the Broken rules count reflects the change.
>Later in the process this Business object along with others attempt to save the data via the Business Objects save() method.
>Lets call this step 2.
>When saving the Business object fires its checkrules logic, this is checking additional rules related to the data the Business Object is saving. If one of these rules fail than it behaves just as one would expect. The broken rules from this step are added to any rules that where broken during step 1 and returns rulesfailed save result.
>However if no rules from step 2 fail then saverulespassed is returned and the rules provider is empty with no broken rule count .
>
>While troubleshooting this I did checkrules() from the business object instead of a save() then everything is back to working correctly regardless whether an of the rules in step 2 failed.

The AutoCheckRules property was specifically designed to determine if rules are cleared before CheckRules() is executed. However, CheckRules() is also called in a few other places:

CancelTableRows()
CancelEntityList()
PreSaveProcessing()
PreSaveEntityListProcessing()
PreSaveEntityProcessing()

It sounds like you want AutoCheckRules to also apply in the “Save” methods…is that right?