Latest Contributions by HusseinNasser2

‎07-25-2023

The easiest way is to set the rule to execute on Insert, and then change the split-policy on the line to delete-insert-insert. This way when you do a split, what will really happen is 3 events The original long line will be deleted. (if you have a delete AR it will trigger here) the first segment will be inserted (to the left anchor) and attribute rule will be triggered the second segment will be inserted (to the right of the split anchor) and attribute rules will be triggered on insert all attributes are preserved from the original line (essentially duplicated) you can handle the same thing with the existing split policy (update insert) its just little harder. you can change the split policy from the properties of the class.

‎07-25-2023

One way is to make an make a change to a batch calculation rule (e.g. add a comment), this will reset all batch calculation validationstatus. The other way to edit to the features (any field will reset the validationstatus)

‎07-18-2023

Correct, if you were using the geometry on the citylimit feature then you would want to return geometry. I think you need to guard against null. As First() might not return any result. var fs = FeatureSetByName($datastore,"City_Limits",["TOWN"],false); var intFs = Intersects(fs, Geometry($feature)); var cityLimit = First(intFs) //if the cityLimit feature is null do an early exit. if (cityLimit == null) return; return { 'result':{ 'attributes':{ 'MUNICIPALITY':cityLimit.TOWN } } }

‎06-22-2023

This bug can be tracked here BUG-000158046 it was fixed and ported to 2.9.10 and will be addressed in 3.1 and 3.0 patches

‎06-22-2023

Thanks Gregory for sharing this, anytime you find something doesn't make sense please do let us know. There is sure a bug here, if this is the code you are using. I expect the order matter when you have an early exist (like a check with a return) where the rest of the code won't be checked even if it has a bug. But that doesn't seem to be the case for your code Can you share what Pro were you using? what database platform is it on (enterprise ( if yes is it oracle/sqlserver etc.. ) or filegdb/mobile etc) and maybe the schema of your class? an XML export with no data is sufficient. that will help us narrow down the cause. one more thing , make sure to use haskey to check the dictionary pipeGradeDict otherwise you will get a field not found error when the value isn't part of the dictionary. Keep in mind the arcade validation uses the first row in the table as a candidate for validation, if table is empty, we create a dummy row with default values initialized for validation. the string type expected error can only happen if you are passing a number as the key where a string is expected. p.s. I couldn't reproduce with 3.1 , 3.0 or 2.9.10 when I move the line up t & d validation just works, yet again I created my own table with your fields there might be more to your specific Pro/dbms schema and data.

‎06-12-2023

correct, the error layer points to the error table.

‎06-12-2023

not pretty, but you can delete the rule that the error points to and that should delete all the error features, you can simply just recreate the rule again. Careful that this also deletes all error features not just orphaned ones. I think disable/enable also does the same thing (I might be wrong)

‎06-12-2023

Hey Drew, that should technically not happen. and if it does it is probably a bug, When you delete the source feature, we also delete all errors associated with this feature. Is it possible that the delete happened outside of software (like in SQL? ) Would be good if you have a repro case for how errors are orphaned.

‎06-12-2023

That is correct, when you modify a validation or batch calculation rule, all rows in that table will reset its validationStatus (a field we use to know what to pick up during evaluation) to "dirty" which means mark them as require validation or calculation depending on what rules you have. The next evaluation will pick all the rows and either generate more errors or remove the existing errors if they are not longer valid. For example: You have a table with 10 rows and validation rule that return false. (which means all rows are errors) you run evaluate and now you get 10 error features. and all 10 rows says clean (no require validation). If you evaluate again it no-ops and no rows are evaluated. (performance thing) If you change the validation to return true, we touch all 10 rows to make them require validation. so each row will be evaluated and the row errors will be deleted because the rule evaluate to true. you will end up with no errors and 10 rows that require no evaluation.

‎06-08-2023

Hey @Chip727 Can you try to Exclude the rule from client evaluation and confirm if the error goes away? Make sure this option is checked.

‎05-09-2023

I appreciate the work MVPs are doing here in the community, especially in the attribute rules section which is getting lots of traction thank you !

‎05-09-2023

This bug will be addressed in 3.1.2 Please use BUG-000157390 for tracking.

‎05-04-2023

Good catch @JohannesLindner updated post thanks!

‎05-04-2023

Are you getting a field not found error, in 3.1 for an Attribute Rule that worked in previous ArcGIS Pro? The reason is because we fixed a bug in 3.1 with FeatureSetByName that were incorrectly requesting too many fields than requested. FeatureSetByName is a function that allows you to query a table and specify what fields to pull back and whether to return the geometry. The result then can be used in the Arcade script. Here is an example where we have a table `mytable` and we are pulling field1 and requesting not to return geometry. var fs = FeatureSetByName($datastore, "mytable", ["field1"], false); var firstRow = first(fs); return firstRow.field1; Due to a bug in Pro 3.0 and earlier, the software in certain conditions will ignore the requested fields and will return all fields including the geometries during Arcade validations and execution. This means that scripts that should have failed were working here is an example where you only returned field1 but the script is trying to access field2 but the featureset doesn't have it because it only asked for field1 var fs = FeatureSetByName($datastore, "mytable", ["field1"], false); var firstRow = first(fs); return firstRow.field2; //this should fail because field2 is not in the result set. In prior releases this bug masked these scripts errors and continue to work even when the script isn't correct. In Pro 3.1 Pro and Enterprise 11.1 always respect the requested fields and geometry. This is unfortunate because we know a lot of our users have scripts that might now fail in the Pro 3.1/11.1 but the good news is scripts will sure run faster consistently as the software will always make sure to request only the fields set by the user in all execution paths and across all database platforms. How to fix? Pro 3.1 and Enterprise 11.1 will show the line number in which the error is encountered, you can trace back which featureset it came from and make sure that the fields are included. In our example above we got the error on line 3. So we add field2 to the request list. var fs = FeatureSetByName($datastore, "mytable", ['field1', 'field2'], false); var firstRow = first(fs); return firstRow.field2; //this should fail because field2 is not in the result set.

‎05-04-2023

Hey James FeatureSetByName you are only asking for the ZIP5 to be returned, but then you are attempting to access. the zipcode field. To fix this add the zipcode field. See if that helps. That is something we fixed in 3.1 where in some cases prior releases we were fetching all fields regardless of what you asked it to, which is why you script worked before but no longer does. var zip = FeatureSetByName($datastore, 'ZipCodes', ['ZIP5', 'zipcode'], true); var intersectLayer = Intersects(zip, Geometry($feature)); if (Count(intersectLayer) > 0) { var layer = First(intersectLayer); return layer['zipcode']; } else { return null; }

Online Status	Offline
Date Last Visited	2 weeks ago

My Ideas

Latest Contributions by HusseinNasser2

Re: Attribute Rules and Split Road Centerline

Re: What happens to existing errors when validation rules change

Re: Unexpected Null error only when trying to save rule

Re: Arcade expression: Calculation rule to update field upon edit, split

Re: Why does Variable Order in Attribute Rule Expression Matter? Is it a bug?

Re: What happens to existing errors when validation rules change

Re: Orphan Errors - can I delete them?

Re: Orphan Errors - can I delete them?

Re: What happens to existing errors when validation rules change

Re: FeatureSetByRelationshipName Attribute Rule Error

Re: Our Thanks to Esri Community MVPs

Re: Attribute rule not working anymore in 3.1

Re: Does your Attribute Rule fails on 3.1 but works on older release? here is why (field not found error)

Does your Attribute Rule fail on 3.1 but works on earlier releases? Here is why (The field not found error)

Re: Attribute rule not working in 3.1

Re: Attribute rule to merge road centerline addres...

Re: Is it possible to pass dataset name from varia...

Snapping with Attribute Rules

Re: Validation Rules on Feature Layer (branch vers...

Re: Deleting and creating a containment associatio...