Delete in a table1 does not set the value as null in featureclass1, due to another conflicting update rule in featureclass.

[RavindraSingh]

The issue is a conflict between two ArcGIS Pro attribute rules.

One rule, triggered by deleting a record in Maximo_location table, aims to set the maximolocationId field in ElectricDevice  feature class to null. However, a separate calculation rule in ElectricDevice feature class, which triggers on any insert or update, immediately overwrites (this is what I think so, my this assumption might be wrong.) this null value, attempting to re-populate it from Maximo_location (which no longer exists for the just now deleted record).

But by disabling the ElectricDevice update rule confirmed it was the cause, allowing the Maximo_location delete rule to successfully nullify the field.

ArcGIS Pro version: 3.3.1

any inputs ? @HusseinNasser2 

[RPGIS]

Hi @RavindraSingh,

Could you please post a snippet of the code that you are using if it does not contain sensitive information? It sounds like you are trying to accomplish something that similar to what we have since we also use Maximo as well. Well not us but another department that we work with.

[RavindraSingh]

@RPGIS here is the code snippet. 

FYI: There are no relationship classes between these two objects.

Rule1-ToUpdate value in ElectricDevice, whenever any Inser/Update/Delete happens in MaximoLocation table.

/*Rule1-ToUpdate value in ElectricDevice, whenever any Inser/Update/Delete happens in MaximoLocation table. */

var l_tablename = $feature.tablename
var l_obje_ref_id = $feature.objectrefid
var l_id = $feature.id
var l_edits = []

if ($editcontext.edittype == "DELETE") {
    l_id = null
}

if (l_tablename == "ElectricDevice") {
    var l_features = Filter(FeatureSetByName($datastore, "ElectricDevice"), "id = @l_obje_ref_id AND assetGroup == 16")
    if (Count(l_features) != 0) {
        var l_record = First(l_features)
        var l_update_edit = {
            "className": "ElectricDevice",
            "updates": [{
                "objectid": l_record.objectid,
                "attributes": {
                    "maximolocationid": l_id
                }
            }]
        }
        Push(l_edits, l_update_edit)
    }
}

// Return edits to apply in ElectricDevice feature class
return {
    "edit": l_edits
}

Rule-2 on ElectricDevice feauture class, this executes whenever any Inser/Update happends in ElectricDevice

/* Rule-2 Applied on ElectricDevice feature claass, it executes when any Inser/Update happens in this feature class. It's only updates 'maximolocationid' field.*/

var l_asset_grp = $feature.assetgroup
var l_asset_type = $feature.assettype
var l_id = $feature.id

// Check 'ASSETGROUP = 16 AND ASSETTYPE = 0'
if (l_asset_grp == 16 ) {
    var l_features = Filter(FeatureSetByName($datastore, "Maximo_location"), "objectrefid = @l_id AND tablename = 'ElectricDevice'")
    if (Count(l_features) != 0) {
        return first(l_features).id
    }
}

// Deafult return
return $feature.maximolocationid

[RPGIS]

I am confused by the line below. Is there a field called table name.

var l_features = Filter(FeatureSetByName($datastore, "Maximo_location"), "objectrefid = @l_id AND tablename = 'ElectricDevice'")

[RavindraSingh]

Yes, there is a field with name as 'tablename' in 'maximo_location' table.

[MikeMillerGIS]

Not sure what is going on, but calling Count and then First is bad for performance.  Just call First and if there is a result, do something, if not, exit/continue.

Any chance you could share a repo GDB, it is hard to trouble shoot what is going on.

[RPGIS]

It seems like, correct me if I am wrong, that you are trying to filter object ids. This isn't recommended at all, specifically since object ids are unique to each record and can be hard to filter by. This could be causing your issue. 

[RPGIS]

This may resolve your issue but it is hard to say without knowing what common attributes exist between the two datasets.

var lag = $feature.assetgroup
var lat = $feature.assettype
var lid = $feature.id
var ML = FeatureSetByName($datastore, "Maximo_location")
	
// Check 'ASSETGROUP = 16 AND ASSETTYPE = 0'
if (lag == 16 ){
    var F = First(Filter(ML, "maximolocationid =  AND assetGroup == @lag"))
    if(TypeOf(l_features) == 'Feature'){ lid = First( l_features ).maximolocationid }
    }
return lid

var TblName = $feature.tablename
var MaxLocID = $feature.id
var ET = $editcontext.edittype
var RelTbl = FeatureSetByName($datastore, "ElectricDevice")

var l_edits = Null
if (TblName == "ElectricDevice") {
    var T = First(Filter(RelTbl, "maximolocationid = @MaxLocID AND assetGroup = 16"))
	if( TypeOf(T) == 'Feature' ){
		l_edits = [{ "className": l_tablename, "updates": [{ "objectid": T.objectid, "attributes": { "maximolocationid": MaxLocID } }] }]
		}
	}

// Return edits to apply in ElectricDevice feature class
if( ET == 'DELETE' ){ MaxLocID = Null }

var V = { 'result' : {'attributes':{ id: MaxLocID } } }
if( Count( l_edits ) > 0 ){ V['edit'] = l_edits }
return V

[RavindraSingh]

@RPGIS  @MikeMillerGIS 

Based on my limited understanding, the issue appears to originate from Calculation Rule-2 applied to the maximolocationId field in the ElectricDevice feature class. Rule-2 is triggered on insert/update events for ElectricDevice, and may inadvertently overwrite the null value previously set by Rule-1. This occurs because edits pushed to ElectricDevice during a deletion from the Maximo_location table trigger Rule-2 again, causing a conflict.

It seems this behavior might stem from a design-level concern, where the two rules are not harmonized and end up conflicting. I’d really appreciate your insights on whether this approach needs reevaluation.

[RPGIS]

Hi @RavindraSingh,

Is the ultimate goal to have it so that you have a 1:1 corresponding updates so that when one associated record is changed then the other matching record is also changed. It might be easier for anyone to help troubleshoot your issue if you provide a clear expectation/outcome you wish to have.

Example:

• I want the associated record with matching attributes in Tables A and B that update one another
• Table A has [x,y,z] fields and Table B has [a,b,c] fields
• Fields x and a have 123 as matching attributes and fields y and b have 789 as matching attributes
• The expected behavior is:
  
  • When a record in Table A is deleted, the associated attribute in field a of Table B is set to null
  • When field b of Table B is updated and the associated attribute in field y of Table A is populated, populate field b of Table B with the attribute found in field y of Table A

You don't have to go into full detail but the more information the better. Sometimes drawing out the logic flow will sometimes help with situations like this.