Attribute Constraint Rule Discrepancy Across Enterprise Environments

Question

Hey everybody,

I'm encountering an issue with an attribute constraint rule that behaves differently in two enterprise environments, and I'm seeking insights into potential triggers for this behavior.

The attribute constraint rule in question ensures that a specific point feature remains placed precisely on a corresponding line feature. In Environment A, the rule operates as intended. When moving the point feature, the corresponding line feature adjusts appropriately due to the existing UN-relationship, and the rule validation passes.

However, in Environment B, with an identical rule, attempting to move the point feature results in the line feature adjusting as expected, but the rule validation fails. Both rules are the same. I'm reaching out to see if anyone has encountered a similar issue or has suggestions for identifying differences between the environments that might lead to this behavior.

Thanks for your help!

Stefan

MikeMillerGIS · Answer

What environments are A and B. Is one a FGDB and the other a MGDB or EGDB?  Could be an order of edit operations.  If EGDB/Services, can you use fiddler to look at the apply edits operation of the move of the point and see what it includes.

StefanAngerer · Answer

Hi @ChrisMousetis,

Thanks for the quick reply! The rule is actually written in arc arcade looking something like this:

// Get all structure boundaries for intersect operation
	var structureBoundary = FeatureSetByName($datastore, "StructureBoundary", ["globalId"], true) 
	var pipelineLines = FeatureSetByName($datastore, "PipelineLine", ["globalId"], true)

// Check if feature intersects a boundary or line
	if((count(intersects(structureBoundary, geometry($feature))) == 0) && (count(intersects(pipelineLines, geometry($feature))) == 0)){
		return false; 
	} else {
		return true; 
	}

... and yes, the "rule validation failed" is actually wrong phrased. The arcade rule validates. However when trying to update the point feature to a new position. The rule above throws an error indicating that the line did not move along correctly. Regarding your first three points: I think they are all not the problem, but I have to double check them, but thanks for bringing it up again!

The 4th-Point is something I didnt knew existed. I will check if that will bring a solution.

Will keep you updated!

ChrisMousetis · Answer

@StefanAngerer , can you elaborate on what you mean by "the rule validation fails". Does that mean the rule is producing an error and preventing you from moving the features? Or does that mean the rule is not functioning?

Pending that, a few things you might want to check between environments are:

1) If this is a rule w/an Arcade expression (as opposed to a "Ready to use Rule"), you might double check the names of the feature classes across both databases and make sure the code is updated as needed in each environment.

2) This is an easy one...but are the ArcGIS Pro versions the same in both environments?

3) Depending on what the rule is relying on to confirm the points are exactly on the lines, you might check the snapping tolerance in the Pro projects and the XY tolerance in the feature dataset properties in both environments.

4) If this involves features in a utility network, you can also check the Connected/Disconnected setting on the "Move" tool in both environments.

Hope that helps. I'm interested to learn what the culprit is.