topic Re: Delete in a table1 does not set the value as null in featureclass1, due to another conflicting update rule in featureclass. in Attribute Rules Questions

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

RavindraSingh — Tue, 29 Jul 2025 09:57:49 GMT

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

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

RPGIS — Mon, 28 Jul 2025 16:54:00 GMT

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.

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

RavindraSingh — Mon, 28 Jul 2025 17:36:40 GMT

@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

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

RPGIS — Mon, 28 Jul 2025 20:57:39 GMT

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'")

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

RavindraSingh — Tue, 29 Jul 2025 05:40:35 GMT

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

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

MikeMillerGIS — Tue, 29 Jul 2025 23:08:11 GMT

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.

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

RPGIS — Wed, 30 Jul 2025 12:21:47 GMT

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.

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

RPGIS — Wed, 30 Jul 2025 16:13:45 GMT

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

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

RavindraSingh — Wed, 30 Jul 2025 14:59:13 GMT

@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.

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

RPGIS — Wed, 30 Jul 2025 16:45:08 GMT

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.