Select to view content in your preferred language

Attribute rule with subtype insert trigger bug v3.3.2

510
2
10-11-2024 02:46 PM
Labels (1)
CaseyJ
by
Emerging Contributor

I have several feature classes with attribute rules that update an associated feature class table. The update rules are triggered on insert and update, and they have all worked until I recently updated to v3.3.2. Now, I've found that the rules applied to feature classes that do not have subtypes still work, but those applied to subtypes are only triggered on updates now. I faced a similar error awhile back, but it was more widespread and I thought it had to do with timing and failure to fully update the key field with a previous attribute rule, so my script is now a bit clunky.

For reference to help understand my code: I have a point fc (aLocation) that essentially collects the data from other feature classes. Inserting a catchment polygon updates the catchment area value in the point fc table. Inserting a wetland polygon should also add the wetland area to the point fc table and calculate the wetland to catchment ratio. However, the wetland extent feature class has 4 subtypes, and those rules are no longer triggering properly on insert although the wetland feature is correctly inheriting information from the point fc.

Catchment attribute rule - functioning properly, triggered by insert and update:

 

//get the GlobalID of the point feature being updated
//To prevent null errors on insert if the PrjGUID isn't updated prior to this script evaluation, include GetPrjGUID script again here
if ($feature.PrjGUID == null) {
    var PrjArea = FeatureSetByName($datastore,"aProjectArea",["PrjGUID"])
    var PrjMatch = intersects($feature, PrjArea)
    var MatchCount = count(PrjMatch)
    var Match = first(PrjMatch)

    // Return the PrjGUID value of the project area if exactly 1 area intersects target feature
    var PrjKey = IIF(MatchCount == 1, Match.PrjGUID, null)
    } else {
    var PrjKey = $feature.PrjGUID}

var fsLoc = Filter(
            FeatureSetbyName($datastore, "aLocations", ["PrjID","Catchment","GlobalID"],false), 
                   "GlobalID = @PrjKey")
//if we couldn't find it generate error message (someone might've deleted it)
if (count(fsLoc) == 0) return {"errorMessage": "Failed to update acres in Location attributes, no 1:1 match."}

if (count(fsLoc) > 0 ) {
//get the feature row (we should only have one )
var fLoc = first(fsLoc)

return {
      //we want to just return the value of field `Acres` no change require
      "result": $feature.Acres,
      //this keyword indicates an edit that needs to happen, it's an array since we can make many edits
       "edit": [{  
              //the other class we want to edit
               "className" : "aLocations",
               //the type of edit, in this case we want to update so we say `updates`, its an array since we can make many updates
               "updates" : [{ 
                            //what feature we need to update? we can either find it by the globalid or the objectId
                            "GlobalID" : fLoc.GlobalID,
                            //what do we want to update (we can optionally add attributes property and update properties there)
                            "attributes":
                               { "Catchment": $feature.Acres
                                }//close attributes block
                           }]//close updates block and array
                }] //close edit block and array   
       }//close return block
}

 

 

Wetland extent attribute rule - NOT functioning properly; triggered by insert and update, applied to subtype 'pool'. (Updates do trigger the rule, but not insert)

 

//get the GlobalID of the point feature being updated
//To prevent null errors on insert if the PrjGUID isn't updated prior to this script evaluation, include GetPrjGUID script again here
if ($feature.PrjGUID == null) {
    var PrjArea = FeatureSetByName($datastore,"aProjectArea",["PrjGUID"])
    var PrjMatch = intersects($feature, PrjArea)
    var MatchCount = count(PrjMatch)
    var Match = first(PrjMatch)

    //Return the PrjGUID value of the project area if exactly 1 area intersects target feature
    var PrjKey = IIF(MatchCount == 1, Match.PrjGUID, null)
    } else {
    var PrjKey = $feature.PrjGUID};

var fsLoc = Filter(
            FeatureSetbyName($datastore, "aLocations", ["PrjID","Catchment","Pool","PerWS","GlobalID"],false), 
                   "GlobalID = @PrjKey")

//if we couldn't find it generate error message (someone might've deleted it)
if (count(fsLoc) == 0) return {"errorMessage": "Failed to update Location attributes, no 1:1 match."}

if (count(fsLoc) > 0 ) {
//get the feature row (we should only have one )
var fLoc = first(fsLoc)
var WS = fLoc.Catchment

return {
      //we want to just return the value of field `Acres` no change require
      "result": $feature.Acres,
      //this keyword indicates an edit that need to happen, its an array since we can make many edits
       "edit": [{  
              //the other class we want to edit
               "className" : "aLocations",
               //the type of edit, in this case we want to update so we say `updates`, its an array since we can make many updates
               "updates" : [{ 
                            //what feature we need to update? we can either find it by the globalid or the objectId
                            "GlobalID" : fLoc.GlobalID,
                            //what do we want to update (we can optionally add attributes property and update properties there)
                            "attributes":
                               { "Pool": $feature.Acres,
                                 "PerWS" : iif(isempty(WS),null, round((($feature.Acres/WS)*100),2))
                                }//close attributes block
                           }]//close updates block and array
                }] //close edit block and array   
       }//close return block
}

 

 

2 Replies
JohnGalambos
Occasional Contributor

I've confirmed with ESRI Canada this is a bug. Even with a minimal subtype feature class within a file geodatabase, ArcGIS Pro 3.4.2 will not run immediate calculation attribute rules that are triggered based on inserts of a subtype. Updates work fine. 

This appears to also affect published registered feature services connected to a SQL Server enterprise geodatabase. Interestingly, there the attribute rules will sometimes trigger on insert, but it's not reliable.

CaseyJ
by
Emerging Contributor

Good to know ESRI Canada confirmed it was a bug! I was working with ESRI support as well, and they reported mixed results with their testing so they were unable to confirm whether it was a bug. In troubleshooting we did encounter another bug though - the layouts (and any layout elements) I created in earlier versions of Pro could not be copied into new projects created in the current version of Pro. Any layouts with items copied in from templates created in earlier versions exported blank pages. I am still in the process of recreating all of my layout templates from scratch after completely updating my data organization and ArcPro project files during attempts to troubleshoot this attribute rule bug.