<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Immediate calculation attribute rule, querying $datastore in ArcGIS Pro Questions</title>
    <link>https://community.esri.com/t5/arcgis-pro-questions/immediate-calculation-attribute-rule-querying/m-p/1552008#M89465</link>
    <description>&lt;P&gt;From my testing, replica synchronization (i.e. what offline areas use to update the feature service) appears to attribute rules as series of individual features to C/U/D. If FeatureSetByName is reading the data outside of the current transaction, it'll just see the pre-sync snapshot which will not include new features or changes to those features. If it's reading data from within the current transaction, it&amp;nbsp;&lt;EM&gt;might&lt;/EM&gt; see the other operations but it might not, depending on the execution order, so you should always assume it can't.&lt;/P&gt;&lt;P&gt;The safest option is to assume that this type of query could or could not contain the current feature; therefore, always read/modify the input feature in addition to what you get from the query, but also assume this could result in a duplicate action and guard accordingly. This will cover both standard and sync updates. If this'll bloat your scripts too much, test how the rules behave in your environment from a variety of clients, offline&amp;nbsp;&lt;EM&gt;and&lt;/EM&gt; online.&lt;/P&gt;</description>
    <pubDate>Thu, 24 Oct 2024 18:36:26 GMT</pubDate>
    <dc:creator>DavidSolari</dc:creator>
    <dc:date>2024-10-24T18:36:26Z</dc:date>
    <item>
      <title>Immediate calculation attribute rule, querying $datastore</title>
      <link>https://community.esri.com/t5/arcgis-pro-questions/immediate-calculation-attribute-rule-querying/m-p/1552001#M89461</link>
      <description>&lt;P&gt;We have a fairly complex Arcade script that executes on Enterprise Geodatabase feature class &lt;STRONG&gt;Insert via a sync from an offline area in the field maps app.&lt;/STRONG&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;If we query the feature class using Filter(FeatureSetByName()), the returned feat_set does not contain $feature that triggered the attribute rule.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;LI-CODE lang="c"&gt;var calcFeatId = -99;
var sqlexpression = "feat_id = @calcFeatId"
var feat_set = Filter(FeatureSetByName($datastore,'mydb.dbo.pt_layer',['globalid'],false),sqlexpression);

return {
            'attributes':{ //values to calculate on $feature
                'feat_id': calcFeatId
            }
        };&lt;/LI-CODE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Is this expected behavior?&amp;nbsp;&lt;/P&gt;&lt;P&gt;Further, what if that same attribute rule modifies attribute values of $feature. Would the above query include $feature in the filtered featureSet?&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 24 Oct 2024 18:21:33 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-pro-questions/immediate-calculation-attribute-rule-querying/m-p/1552001#M89461</guid>
      <dc:creator>danbecker</dc:creator>
      <dc:date>2024-10-24T18:21:33Z</dc:date>
    </item>
    <item>
      <title>Re: Immediate calculation attribute rule, querying $datastore</title>
      <link>https://community.esri.com/t5/arcgis-pro-questions/immediate-calculation-attribute-rule-querying/m-p/1552008#M89465</link>
      <description>&lt;P&gt;From my testing, replica synchronization (i.e. what offline areas use to update the feature service) appears to attribute rules as series of individual features to C/U/D. If FeatureSetByName is reading the data outside of the current transaction, it'll just see the pre-sync snapshot which will not include new features or changes to those features. If it's reading data from within the current transaction, it&amp;nbsp;&lt;EM&gt;might&lt;/EM&gt; see the other operations but it might not, depending on the execution order, so you should always assume it can't.&lt;/P&gt;&lt;P&gt;The safest option is to assume that this type of query could or could not contain the current feature; therefore, always read/modify the input feature in addition to what you get from the query, but also assume this could result in a duplicate action and guard accordingly. This will cover both standard and sync updates. If this'll bloat your scripts too much, test how the rules behave in your environment from a variety of clients, offline&amp;nbsp;&lt;EM&gt;and&lt;/EM&gt; online.&lt;/P&gt;</description>
      <pubDate>Thu, 24 Oct 2024 18:36:26 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-pro-questions/immediate-calculation-attribute-rule-querying/m-p/1552008#M89465</guid>
      <dc:creator>DavidSolari</dc:creator>
      <dc:date>2024-10-24T18:36:26Z</dc:date>
    </item>
    <item>
      <title>Re: Immediate calculation attribute rule, querying $datastore</title>
      <link>https://community.esri.com/t5/arcgis-pro-questions/immediate-calculation-attribute-rule-querying/m-p/1552045#M89472</link>
      <description>&lt;P&gt;Thanks David. Yes, Count(FeatureSetByName) returns a different number depending on replica sync, vs. inserting a feature using Pro.&amp;nbsp;&lt;/P&gt;&lt;P&gt;VERY confusing and not documented at all (at least from what I could find).&amp;nbsp;&lt;/P&gt;&lt;P&gt;This arcade script is already bloated at 500 lines. Could be trimmed down if I take some more time, but complex. I really see no other alternative to firing a script by insert trigger. Maybe a feature service webhook would be more reliable. Better yet, that webhook calls powerAutomate flow, that invokes an Azure python runbook...&lt;/P&gt;</description>
      <pubDate>Thu, 24 Oct 2024 19:29:05 GMT</pubDate>
      <guid>https://community.esri.com/t5/arcgis-pro-questions/immediate-calculation-attribute-rule-querying/m-p/1552045#M89472</guid>
      <dc:creator>danbecker</dc:creator>
      <dc:date>2024-10-24T19:29:05Z</dc:date>
    </item>
  </channel>
</rss>

