Hi,
I am currently experiencing an issue with a Feature Service when creating a large number of features.
I have an attribute rule on a field named UID, which calls a sequence to generate a unique identifier using the following expression:
'S' + NextSequenceValue('s100.seq_UID')
This works perfectly in both file geodatabases and enterprise geodatabases. However, when working with a branch-versioned enterprise geodatabase published as a Feature Service, the UID field is often empty immediately after calling CreateRow() and attempting to read the value from the returned feature:
var feature = featureClass.CreateRow(buffer);
The UID field does appear to be populated at some point, but it is not available in the returned feature object at the time I need it. Unfortunately, I require the UID value immediately within my code workflow.
Could you please advise why this behavior occurs in a branch-versioned Feature Service environment, and how I might implement a reliable solution?
Any suggestions would be greatly appreciated.
Best regards,
Jens Christiansen
Hi,
It would be nice to see piece of your code. How do you use CreateRow? Are you using editOperation.Callback as in sample here? Are you calling context invalidate for feature:
context.Invalidate(feature);
I'm running my code as a Hosted application so it is actually a console application using the ArcGIS Pro SDK.
That said I actually only open the feature class, create a RowBuffer, add some attributes and then call CreateRow. The returned feature doesn't always contain the updated attribute initialized by the AttributeRule which then breaks my code since I need that generated value.
If I just continue the attribute is generated at some point but "long" time after I call CreateRow.
So all in all it seems that attribute rules aren't executed doing CreateRow like on any other supported database which then makes it pretty difficult to use Attribute Rules for this kind of scenario.
I'm using the Attribute Rule to create a global ID - which isn't the GlobalID but something a bit simpler 🙂
Best regards,
Jens Christiansen