Problems trying to implement attribute rule example in Pro documentation

[AndrewZimba1]

Hello everyone,

I'm trying to implement essentially the same functionality as in one of the examples in the Pro documentation at Attribute rule script expression examples—Geodatabases | ArcGIS Desktop, specifically:

var fsStructureBoundary = FeatureSetByName($datastore, "Substation", ["name"], true)

var fsSubstation = Intersects(fsStructureBoundary, Geometry($feature))

var substation = First (fsSubstation)

var subname = ""

if (substation == null)

return {"errorMessage": "Transformers must be created in a substation."}

else subname = substation.name

return subname + " - " + $feature.assetid;

Of course my feature class names are different, but when I validate the expression I get:

Invalid expression

Error on line 1

Table not found {FC}

I've tried the FC name as it appears in the TOC, the name of the source FC in the geodatabase, and the full Database.DBO.FC source all with the same result.

What am I missing?  

[HusseinNasser2]

Hey Andrew,

That error means that FeatureSetByName could not find the table name {FC} Means the table {FC} could not be found. Can you paste your script and a picture of your geodatabase schema?

The `$datastore` global in FeatureSetByName must be your geodatabase workspace, so make sure that the table Name you specify is the physical table name in your geodatabase not the layer name.

Hope that helps

Here is a video of the talk I gave back in Dev Summit 2019 in Attribute rules with demos from scratch

Attribute Rules in Arcade Video | Esri 

[AndrewZimba1]

Thank you Hussein!  It looks like I had to get the FC name in there without the gdb.DBO. prefix AND get the field name containing the attribute in there to get it to recognize the table.

The expression now checks as valid.  HOWEVER, when I go to save the "Applying changes" progress bar just rolls and rolls.

Do these attribute rules have to be applied before services are published from these feature classes?  Does versioning/archiving have to be off?  Any details like that I should be aware of?

[HusseinNasser2]

Hey Andrew,

Yes you only add the "gdb.DBO." prefix if you are not the owner of the dataset. if you owner the dataset you can just use the name of the class.

Attribute rules are considered schema change so all connections should be closed before a change can be done.. this includes stopping services. (Exclusive lock required)

You can add them to any dataset with any registration type versioned or unversioned. 

[AndrewZimba1]

Thanks again Hussein!  

Quick clarification on the gdb.DBO thing - this rule is designed to take effect when other users add points to the FC thru Collector.  Since they aren't owners, do I need to explicitly put in the gdb.DBO, or is it only when authoring the rule where that applies?  In other words, once the rule is "in there" since I put it in and don't need the gdb.DBO, will it evaluate correctly when others insert points?

[HusseinNasser2]

Assume you have a user called "gdb" and you connected to the workspace with "gdb" user , you can create the attribute rule using FeatureSetbyName (  "gdb.dbo.TreeTable" ). You can also just say FeatureSetbyName ( "TreeTable") (you can do that because gdb owns the table). Regardless what you write we will ALWAYS persist it internally fully qualified "gdb.dbo.TreeTable" If a user "test" try to connect to the workspace and tried to execute the attribute rule (made an edit) then it will query the table "gdb.dbo.TreeTable"  which means test must have access to the table "gdb.dbo.TreeTable" 

[AndrewZimba1]

Perfect.  Thank you for all your help.  One more for the road: How could I turn this script inside out and say "If a polygon contains a point from a specific fc, calculate a field attribute in the polygon fc to 'yes'"?

[HusseinNasser2]

The correct way of implementing this is little bit more complicated. The easier way can be by having one rule on the polygon class that activates on insert/update and does the query and populate the field. but the problem with this approach is if you move the points then the polygon fields are no longer consistent, you will have to go and make a bogus edit to the polygon to activate the attribute rule.

assume you have the following schema

polygonClass (fields: hasPoint)

pointClass1

//rough script on the polygon class to the hasPoint field

var fsPointClass1 = FeatureSetByName($datastore, "PointClass1", ["objectid"], false);

if (Count(Intersects(fsPointClass1, $feature)) > 0)
    return "yes"
else
   return "no"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[AndrewZimba1]

This is perfect Hussein.  Thank you!

I do sheepishly have to say I did think of another attribute rule application question over the weekend.  I'll post that in a separate thread as it's slightly different in scope (I think).

Your assistance has been extremely helpful.  Thank you again!

[AndrewZimba1]

BTW Hussein, this is probably a big enough and useful enough topic that you could write a very successful book on the subject.  These tools may finally give us the ability to build out Collector apps from the desktop that are on par with ArcPad wrt data validation and conditional attribution.