Latest Contributions by HusseinNasser2

‎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; }

‎05-04-2023

Hello, let me add context to why you are getting this object not found error at least in this particular case. Simplifying the script you have to the following there is a condition that when met, you define a variable inside the if block and set it to a value. Later outside the scope of the if block you do another if and use that variable. This is variable scoping, the variable isLeft will only be defined if the first condition is met Now if the first condition was not met, the variable isLeft will never be defined and the second if will fail with isLeft object is error. This is because Arcade has inherited its behavior from Javascript. Why did this work in 3.0 and not in 3.1? Well I could argue that the script may also fail in 3.0 or any release as well if $feature happened to not satisfy the first condition which leads to the variables to not getting defined. I think you can reproduce this in 3.0 by creating a feature outside Test_Jurisdictions. So the real solution for more predictable script is to define the scripts outside the scope. that is move isLeft and IsRight so they are at global scope if you are planning to use them across the script. If there are any other cases where the script fail but the syntax looks correct please post it in the this thread and we will take a look. Hope that clarifies it. Thank you and apologies for the late reply.

‎04-04-2023

I see that you already implemented the change requested by Mike but still get the same behavior as you illustrated on another post. My guess since you are using 10.7.1 it could be a bug that we fixed in the next releases. Try the following script as a workaround // get the feature with the highest id var m = FeatureSetByName($datastore,'oncf.dgf.urb_projet', ['*']); //remove $feature from the equation. var oid = $feature.objectid var s= filter(m, "code_urb like 'URB%' AND objectid <> " + oid) var max_feature = First(OrderBy(s, "code_urb DESC")) // get the number of that id var max_number = 0 if(max_feature != null) { // no features in featureset? -> this block is skipped and max_number is 0 var txt = Replace(max_feature.code_urb, "URB", "") max_number = Number(txt) } // calculate and return the new id return "URB" + Text(max_number + 1, "00000") ound

‎03-17-2023

If you use FeatureSetByname with $datastore and exclude the rule from application evaluation, the rule should work on the server as long as the container (assembly I assume?) is in the workspace which it should be in case of the UN. if those are related with containment associations you can use FeatureSetByAssociation https://www.esri.com/arcgis-blog/products/utility-network/data-management/featuresetbyassocaitions-new-utility-network-arcade-api-to-work-with-associations-2-5-10-8/

Online Status	Offline
Date Last Visited	‎03-19-2026 06:14 AM

My Ideas

Latest Contributions by HusseinNasser2

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 not working in 3.1

Re: attribute rule fire twice

Re: Attribute Rule to calculate Property ID for Meter record

Re: Attribute Rule [Constraint]: Combining GetUser...

Re: Attribute Rule [Constraint]: Combining GetUser...

Re: applyEdits in squence - FeatureService vs. Lay...

Split with Attribute Rules

Temporarily Disable Attribute Rules