topic Re: Relationship classes in Feature Service in Publishing and Managing Services Questions

Relationship classes in Feature Service

FlorianSteiner — Tue, 30 Mar 2021 16:34:34 GMT

Hi there,

we are having some issues, possibly related to relationship classes. We use Feature Services to edit Features using WebGIS (JS API). There is one Service containing a layer based on a feature class (point features), which is in a relationship class with another feature class (polygon). It is a composite 1-M relationship, that moves the polygons, whenever the point is moved. Important to mention: The feature class is located in an enterprise GDB, based on SQL Server. We also use SQL-Triggers to automate some tasks.

That normally works fine. However, under some circumstances, the edit fails (service-response: error 500, "Unable to perform applyEdits operation."). This seems to be the case if the SQL-Trigger and the relationship class both try to edit the related features.

BUT: If we do the same edit in ArcMap using a direct GDB-Connection, there is no problem. There is also no problem if the SQL-Trigger is disabled. Only the combination triggered via a Feature Service seems to produce some kind of conflict.

I read (Prepare data to publish a feature service—ArcGIS Server | Documentation for ArcGIS Enterprise) that the related layer has to be part of the service. However, it only says "table", not "feature class". I still tried this and, surprise, it didn't help.

Any ideas on that?

Re: Relationship classes in Feature Service

JoeBorgione — Tue, 30 Mar 2021 17:00:07 GMT

We also use SQL-Triggers to automate some tasks

I wonder if the argument can be made to abandon your triggers in favor of attribute rules. In a former life I used SQL triggers in a SqlServer backend SDE (now enterprise) and I was under the impression then that triggers were not a supported feature for ArcGIS.

Re: Relationship classes in Feature Service

FlorianSteiner — Wed, 31 Mar 2021 08:52:25 GMT

Hejhej Joe,

thanks for your "out of the box"-answer. We definitely are looking forward for this. However, currently we are not yet using ArcGIS Pro and we have thousands of lines of SQL-code used in triggers, that we can't immediately transfer to attribute rules. I even doubt, that all features are possible with attribute rules.

Best regards
- Florian