|
POST
|
Constraint rules are always evaluated after Immediate calculation rules in the execution order. I'd like to request few details to understand the context, Is the SQL Geodatabase client server direct connect Or published through a service? And What is the versioning model and DBMS? Also the Pro used and Enterprise Versions. While you get those try the following, turn off "Exclude from application evaluation" on the constraint rules and calculation rules.
... View more
08-24-2021
12:29 PM
|
0
|
0
|
2127
|
|
POST
|
The constraint rule does the following: Only allow features to be edited/created when their status is 1 and the street_id is null. Any other value, fail the edit which is what you are experiencing. You might want to define your logic more explicitly. I'm assuming you want to ONLY fail when the status is 1 AND the street_Id is not NULL. You can specify your logic this way. if ($feature.street_status==1 && $feature.street_id != null)
return false;
else
return true;
... View more
08-23-2021
04:32 PM
|
1
|
0
|
2198
|
|
POST
|
That statement is correct and should work p.s. it is not Arcade, it is SQL.
... View more
08-20-2021
09:05 AM
|
1
|
0
|
1752
|
|
POST
|
You can continue using first but first (no pun) you have to add an additional filter against the polygon you want. Push the query all the way to the DB. var cabs = FeatureSetByName($datastore, "Proposed_OLT_LCP_Boundaries_copy", ["cab_id"], false)
var filteredCabs = filter(cabs, "cab_id='SDY-HUT'")
var cabsInt = Intersects(filteredCabs , $feature)
var cabSpliceInt = First(cabsInt)
if (cabSpliceInt == null) return {"errorMessage": "Please edit inside a cabinet boundary"}
return true;
... View more
08-20-2021
08:14 AM
|
0
|
2
|
1755
|
|
POST
|
FeatureSetByName does not support dynamic class names. The name of the class has to be available during static analysis of the script so we can build out the relations in the catalog. (E.g. if you copy Class A which has an attribute rule that reads from Class B we also copy Class B too) here is more details explaining why Why FeatureSetByName doesn't work with variables https://community.esri.com/t5/attribute-rules-blog/why-featuresetbyname-doesn-t-work-with-variables/ba-p/1541572
... View more
08-20-2021
08:03 AM
|
1
|
1
|
2615
|
|
POST
|
The if statement is an invalid syntax. You are comparing a feature (first(fsResult)) to a value $originalfeature.cab_id. Plus don't use IN, use == instead and compare the actual values That being said, I'm not sure what the rule is trying to do, maybe provide a brief description of what the rule is suppose to do? Going by your statement if you want to prevent deletion of features it is a matter of simply creating a constraint rule that returns false. return false;
... View more
08-12-2021
08:19 AM
|
1
|
2
|
2487
|
|
POST
|
Yes you will need to use the error inspector to trigger the validation rules. That will create an error feature showing you where the duplicates are watch this youtube video where I show how to create and evaluate. Note that you can run validation rules and batch calculation rules on filegdb.
... View more
08-11-2021
05:38 PM
|
0
|
4
|
5107
|
|
POST
|
//detect duplicate var currentAssetId = $feature.assetId var currentObjectId = $feature.objectid var fsMyClass = FeatureSetByName($datastore, "myclass") var fsResult = filter(fsMyClass, "assetid = @currentAssetId and objectid <> @currentObjectId") // search for the same asset id but don't count the current row if (first(fsResult) == null) return true; //we did not find a duplicate else return false; //we did find a duplicate create an error feature A bit slow but should work. Alternatively you can do a summary statistics on the class and detect where count > 1
... View more
08-11-2021
02:01 PM
|
0
|
6
|
5119
|
|
POST
|
Thanks, this is a known bug the Add Error Layer should always light up if your workspace supports validation capability. Right clicking on Anno or dimension layers doesn't allow you to add the error layers, but you can simply right click on any feature layer and that option should be available for you.
... View more
06-01-2021
04:33 PM
|
0
|
0
|
1815
|
|
POST
|
You will start seeing the reliance of GlobalId in the new built system as a globally unique identifier instead of the object Id. Utility Network, Version Management, Sync, and yes Attribute rules. The systems become so tightly integrated together it is just easier to always require globalId so those system can interact with each other effectively. For attribute rules and validation and batch calculation in particular, we persist globalId of the source feature in the validation error tables. We also display the globalId of the feature that failed a constraint rule. And to answer the question, globalIds are not preserved by default when transferring data, you will have to make sure its preserved by checking that box. It is not on by default so that it doesn't break old workflows. For instance you have to preserve GlobalIds in the case of utility network because those globalids are referenced everywhere, but you don't necessarily have to preserve the GlobalId for tables with attribute rules
... View more
05-27-2021
09:15 AM
|
2
|
5
|
4752
|
|
POST
|
This is by design. The edit session on the unversioned archived class can't be used to edit the target versioned class. You can however do the opposite, If you had your attribute rule on a versioned class you can let it edit a row in an unversioned class.
... View more
04-27-2021
01:34 PM
|
3
|
0
|
3786
|
|
POST
|
Is the target class has the same version registration as the source class where the attribute rule reside?
... View more
04-27-2021
01:15 PM
|
1
|
2
|
3800
|
|
BLOG
|
Hey Johannes, In most cases you can tell if the rule has been executed if a value has been set to a certain field. In our example if $feature.c has changed that indicates that the client has already performed and persisted the value to c and is now sending us the value of c along side a and b. We released a global $originalFeature that would allow you to compare the original value of the field compared to the new value that is about to get set. So subsequent edits to a and b will produce new c values and you can compare if $feature.c is not equal $originalFeature.c then it means the client has already performed the calculation. Of course this isn't straight-forward to implement and there are other gotchas as well to be discussed like making sure the client doesn't just mock with the value of c directly by making the field read only or hidden. The compute in our example here is obviously trivial but the logic is applicable to complex Arcade expressions in a similar fashion
... View more
04-21-2021
02:42 PM
|
1
|
0
|
11434
|
|
BLOG
|
Attribute rules are scripts authored in Arcade and added to classes in the geodatabase to enforce constraints, calculate fields, query or edit classes in the same geodatabase. Many properties can be set while authoring attribute rules, the name of rule, subtypes the rule applies to, when to trigger the rule and yes Exclude from Application Evaluation. This option has raised many questions in the community so I thought I'd write a blog discussing the purpose of this property and when one should use it. Attribute Rule Execution Attribute rules are stored in the class, so wherever the geodatabase go, the rule goes with it. The rule always executes in the backend geodatabase datastore, whether you initiated the edit from Pro, Collector or Javascript API. Some applications are capable of understanding and executing the rule locally BEFORE the edit request is sent to the backend geodatabase datastore to be executed again. Application vs Backend It is important to differentiate between the application and the backend geodatabase workspace. ArcGIS Pro is an application and feature service, file or mobile geodatabase, enterprise geodatabase are the backend geodatabase workspace. So if I add my filegdb class to Pro and edited the class, Pro can perform the edit locally before "sending" the edit request to the filegdb workspace. This concept is applied to any workspace, services, enterprise geodatabase, mobile geodatbase and file geodatabase. You can see this behavior in Pro's attribute pane window while the Auto Apply option is turned off. Here is an example where we have an attribute rule that adds field a to field b and store the value in field c. The rule has allowed for application evaluation. Exclude from Application Evaluation When unchecked, "Exclude from Application Evaluation" property tells the application that its "safe" to execute this rule locally before sending the edit request to the backend. So you get the behavior like the attribute pane in place execution without the need to persist your edit to the backend to see the rules effects. Smart applications can look at this property and decide to leverage local attribute rule execution if it supports it. As for the time writing this blog, ArcGIS Pro is the only application that is capable of executing attribute rules locally. Here is the same rule from before but with Exclude from Application Evaluation turned on. Noticed that local edits in the pane does not trigger the attribute rule until applying the edit to the workspace. Constraint rules benefit the most from having the application execute the rule locally. If the application executes the constraint rule locally and finds that the rule is violated, an applyEdits request is never sent to the server since we know the request is going to fail there too. This saves on network bandwidth in certain case. Note that the constraint rule is always re-executed on the server side. Another benefit of allowing the application to execute the rule locally is offloading heavy attribute rule compute to the application (when applicable) and only send the final result to the backend. The attribute rule has to be written in such a way to allow for the server to skip computation that has been already performed in the client. This way the server consumes less resources and editing throughput improves. When to Exclude my Rule from Application Evaluation? There are use cases where you want to exclude a rule from application evaluation here are a few. Application doesn't support certain Arcade functionality Even if the application is capable of executing attribute rules locally, not all Arcade functionalities are applicable for local execution. Examples are the attribute rules DML ability to edit other features, and working with sequences NextSequenceValue. Attribute rules that use these functionalities must be excluded from client evaluation. Application doesn't have access to tables behind service The application can sometimes have access to only a subset of classes of the backend geodatabase. Lets say a geodatabase has 3 classes class1,class2, class3. A feature service is published from this geodatabase but only class1 and class2 are included as layers. This means an application consuming the feature service only has direct access to class1 and class2 and NOT class3. If there is an attribute rule on class1 that was allowed to be executed locally (exclude from application evaluation was turned off) and that rule is querying class3, that rule will fail because the application wouldn't find class3 in its local workspace. You might have seen this error before "Arcade Error: Table not found" followed by a guid, that error becomes clear once you understand what really is happening. For such cases you need to exclude the rule from local execution, sending the edit to the backend server will eventually execute on the server geodatabase workspace which has access to all classes. Final thoughts If we go back to when we first designed this, I would definitely pick another name for this property. Maybe Allow Application Evaluation?
... View more
04-08-2021
10:30 AM
|
24
|
11
|
16217
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | a month ago | |
| 1 | 03-19-2026 09:52 AM | |
| 1 | 03-19-2026 06:18 AM | |
| 3 | 01-26-2026 02:25 PM | |
| 3 | 01-05-2026 03:50 PM |
| Online Status |
Offline
|
| Date Last Visited |
3 weeks ago
|