Latest Contributions by HusseinNasser2

When you create a feature in the geodatabase it goes into a memory buffer for performance reasons. Additional updates to the feature by its object id will go to the buffer and then finally flushed at one swoop to the database.  This is what happened in your first rule, you created the feature, then asked AR to update the same feature field BEMERKUNG to "Test 2". The AR found that the feature is still in memory and updated the field in memory then flushed it to the database. So the database only saw one insert.    However we can't always do this optimization. This optimization is not performed when a query against the class happens, because the query must see the feature being created (basic database semantics), so when a query happens to the class (that is your second rule where you did a count of the class), we had to flush the inserted feature to the database. Then the AR says wait a minute, we need to update the same feature (that is your return dictionary with objectId), that update actually becomes a physical second update which triggers the attribute rule again, and we go into the infinite cycle.    So as a better practice, the attribute rule need to be written in a predictable way, if you want to updates fields in the same feature use the return "result" dictionary, with this we have knowledge in the AR to update the same row.   Hope that clarifies it.  ... View more

Your attribute rule is correct, the problem is the order of operations and how the relationship record is created. This is something we are trying to address. Relationships are created after attribute rules.  When you add the related record, the related foreign key `.PARENTGUID`  is not populated, so when the insert attribute rule gets triggered, the foreign key .PARENTGUID is null, which of course will fail to find the parent and fail the edit.    Two workarounds,  you can add the relationship record directly to the table and during that insert fill in the parentGUID , this will cause the Insert trigger to have the parentGuid and the rule should work. Another workaround is to make the attribute rule on update and tell users to make a physical update to the related record (update a field etc.. ) to force trigger the update attribute rule.    I understand the workarounds might not be ideal, we are working on a solution not sure how long it will take though.    ... View more

Think of the dictionary you are authoring as creating an association from $feature to whatever feature you specified in the update_class. Specifying FROMTERMINAL means here you are trying to create an association from the $feature so that terminal should exist on that feature.    If the terminal you are connecting to is at the device then use ToTerminal. and you can safely use the string name  A blog detailing this can be found here.  https://www.esri.com/arcgis-blog/products/utility-network/electric-gas/advanced-attribute-rules-creating-utility-network-associations-with-attribute-rules/   As Mike said, you can also use  ^UN_Association if you want more control. (create associations between two assets other than $feature.    Hope that helps ... View more