Select to view content in your preferred language

Ready to Use Validation Rule Relationship doesn't update in Error Inspector unless parent record is also edited

1337
5
09-07-2022 10:22 AM
Sean_Haile
Occasional Contributor

I have a relationship class between a parent feature class and a related table, where I want to ensure there is at least one corresponding related record present for each origin value found in the parent feature class. 

I've created an attribute validation rule on the parent feature class using the "Ready to use" Validation Rule  called "Relationship" in ArcGIS Pro 2.9. and enabled the search goal "Origin unreferenced or null key value" on the attribute rule. When using the error inspector in ArcGIS Pro, the rule correctly flags a feature as missing a related record the first time validation is run. However, if a related record is then generated, and validation is re-run the error persists! The error only seems to resolve if the feature itself is also edited in some way.

Seems like this "Ready to use" validation rule has limited utility if its error persists until the parent itself is edited. If there is a workaround for this (other than directly editing the parent feature in some way), I would greatly appreciate it.

0 Kudos
5 Replies
JayCary
Esri Contributor

Hi,

For clarification, it sounds like you are using a Data Reviewer check to create a validation attribute rule. Is the Phase/status values of the error feature not changing when evaluating the features again after the edit in the destination datasource?

Note: The phase/status fields are enabled from the "Show Status" option on the Error Inspector.

 

0 Kudos
Sean_Haile
Occasional Contributor

Yes you are correct, I am using the Data Reviewer "Relationship" check to create a Validation attribute rule to flag features that do not have a matching key value in a related table.

The documentation of this check states: 

  • The Validation Status attribute values of both the origin and destination data sources referenced in the Relationship Class parameter are ignored during evaluation. For example, input features with a validation status of 0 (No calculation required, no validation required, no error), 1 (No calculation required, no validation required, has error(s)), 4 (Calculation required, no validation required, no error), or 5 (Calculation required, no validation required, has error(s)) are still included during rule evaluation.

The first time the validation evaluation is run, the there is no related record found and the feature's validation status  is set to: 5 (Calculation required, no validation required, has error(s)). However if a related record is then created, and the validation is run a second time, it does not appear that this evaluation is reevaluated, as the error persists.

If the parent record is edited in some fashion, then the feature's validation status gets set to: 3 (No calculation required, validation required, has error(s)) and if the validation is rerun again then the error is finally removed.

So, is there a way to get this Validation to always rerun, even if the parent feature has not been edited since the last validation?

0 Kudos
JayCary
Esri Contributor

Is the phase/status values of the error feature not changing when evaluating the feature again after the edit in the destination datasource?

On the second evaluation, the expected result is for the error feature's phase/status values to change from GUID-6E727B6D-3FB2-4A09-A69C-677991A6465F-web.pngReview/Reviewed to GUID-8B15277A-0866-4808-A592-00584C332A7D-web.png Verification/Acceptable. By default, these columns are not turned-on in the Error Inspector pane.

0 Kudos
Sean_Haile
Occasional Contributor

No, the validation status value in the origin feature class does not change when the related record is generated in the destination table. That's the root of the problem here.

0 Kudos
JayCary
Esri Contributor

Thanks-much for clarifying what you're seeing.

Based on the info provided above, the dev team has been unable to reproduce this issue using Pro 3.0.1 and there have not been any bugs addressed since the check's release that would change its behavior.

I would suggest starting an incident with the technical support team to capture the details of the rule configuration and associated relationship class.