Select to view content in your preferred language

Why FeatureSetByName doesn't work with variables

337
0
09-23-2024 11:22 AM
HusseinNasser2
Esri Contributor
2 0 337

When writing attribute rules, we often tend to use the FeatureSetByName function to reference other tables or classes. However, you might have encountered this error before when using Arcade scripts with attribute rules that utilize this function.

ERROR 160288: The name object is invalid.  (3.3.3, 3.2.4, 3.17, 2.9.13)
ERROR 161022: Attribute Rules FeatureSet functions require a literal text string for table names. (3.4+)

HusseinNasser2_2-1727115434227.png

 

HusseinNasser2_3-1727115450569.png

 


This means you wrote an Arcade expression using FeatureSetByName and passed a variable to the class name parameter. Here is an example:

 

 

 

 

 

 

var class_name = "test";
var feature_set = FeatureSetByName($datastore, class_name);

 

 

 

 

 

 


 
This pattern is not supported, and the error message is intentional to protect against downstream errors, such as issues with publishing, copy and paste, exporting XML workspaces, and various other data transfer operations.

To fix this, find all instances of FeatureSetByName and ensure you are passing a literal string, as shown below:
 

 

 

 

 

 

 

var feature_set = FeatureSetByName($datastore, "test");

 

 

 

 

 

 


 
Why does FeatureSetByName require a literal string?

In ArcGIS Pro 2.3, we added the ability in attribute rules to reference other tables and classes. This created a dependency tree: if class A has an attribute rule that references class B, copying class A should also bring class B with it; otherwise, the editing behavior will be broken in the new workspace.

To support this, in Arcade, we statically analyze the script to determine this dependency and rely on literal strings to find the referenced classes. When using a variable in FeatureSetByName instead of a literal string, we would have to execute all Arcade expressions to find the value of the table, which would slow down the process of saving the rule. Moreover, execution alone is not enough to discover the table name — for example, having FeatureSetByName nested within a condition that might not be reachable during execution would still pose a problem.

Therefore, always use a literal string when working with FeatureSetByName. Note that this is also applicable to FeatureSetByRelationShipClass

About the Author
Software Engineer, Author of several GIS books and Software Engineering Content Creator on YouTube and Anchor.fm podcast