Feature service layer with computed column

08-06-2015 05:04 PM
New Contributor II

I have a query layer published in map and feature service. When I try to add a new feature using applyEdits on that layer I get this error in the log.

Database error: Underlying DBMS error[[Microsoft][SQL Server Native Client 11.0][SQL Server]The column "..." cannot be modified because it is either a computed column or is the result of a UNION operator.].

I removed that column from the query but I still get that error. Is there any way to get the feature service to ignore that column when editing? I'm not sure why it is accessing that column in the first place since I didn't reference it in the attributes object. Is there a workaround or does applyEdits currently just not work with tables that have computed columns?

0 Kudos
2 Replies
New Contributor III

I experienced similar problem a while ago. It seems ESRI doesn's support 'INSERTS' on non-versioned tables with computed column in it. I tested this from ArcMap. Updating existing features works fine however inserting new feature throws error mentioned by Joe Joyce.

There is one technical article published by ESRI for this:

30565 - Are Computed/Virtual columns supported in an Enterprise environment in ArcGIS?

IT seems this article was updated on the same day of you posting your question here. (Not sure if this post had any impact on this article)

Article states:

"No, Computed Columns (SQL Server) and Virtual Columns (Oracle) are not supported in the versioned environment in ArcGIS geodatabases. "

One would assume that this means computed columns are supported in non-versioned environment. However it seems in non-versioned environment only 'UPDATES' are supported or only 'UPDATES' work. ( I tested this with ArcGIS 10.3.1 and SQL Server 2012)

@Joe Joice, did you consult ESRI tech support for this or received any inputs from ESRI staff?


0 Kudos
MVP Frequent Contributor

Tilting at windmills here, but could you control the value that "should" be in the column/row with a trigger on the base table? Perhaps an AFTER/UPDATE trigger?

0 Kudos