nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How can I enable "Support Rollback On Failure" for a feature server?

JasonKnisley

Recently we began doing online editing of data by enabling Feature Access on some services, but we are having issues where features are being duplicated because there is no rollback when a failure occurs, and on subsequent attempts features that have been previously created are created again with different object ids. When I look at the service properties I can see that "Supports Rollback On Failure" is false, but I don't see anywhere in server manager where I can enable this. How can I configure my service to support rollback?

edit: fixed title " from conversion from old forums to geonet (to make it wasier to read) -ras

Encontre mais publicações marcadas com

Accepted answers

All comments

PiotrPiech

Did anyone find out how to change parameter "Supports Rollback On Failure" to "true"?

The only information I find about it is here ArcGIS REST API

I have versioned data and still parameters are:

"supportsPerReplicaSync": true,

"supportsRollbackOnFailure": false

HectorMelendez-Alvarado

This value value is define by the layerers that the service references. It has to do with the type of editing environment supported by the layer (version, non-version).

ArcGIS REST API

rollbackOnFailure

//This option was added at 10.1.

Description: Optional parameter to specify if the edits should be applied only if all submitted edits succeed. If false, the server will apply the edits that succeed even if some of the submitted edits fail. If true, the server will apply the edits only if all edits succeed. The default value is true.

Not all data supports setting this parameter. Query the supportsRollbackonFailureParameter property of the layer to determine whether or not a layer supports setting this parameter. If supportsRollbackOnFailureParameter = false for a layer, then when editing this layer, rollbackOnFailure will always be true, regardless of how the parameter is set. However, ifsupportsRollbackonFailureParameter = true, this means the rollbackOnFailure parameter value will be honored on edit operations.

Values: true|false

Example: rollbackOnFailure=true

CallumSmith2

Hi Hector

I have a FC in a SDE GDB that was versioned in another GDB but now it has been copied to another GDB and is no longer versioned. No matter what I do when I publish feature service it always sets "Supports Rollback On Failure" to true. I have other feature services pointing to non versioned featureclasses and this is always set to false. This is causing me heaps of issues as the users cannot update or delete any features.

I have tried to update this parameter using the rest updateDefinition with a json input as {"SupportsRollbackOnFailureParameter": false} but this just throws a 500 error Service does not exist in folder?

How can I change this parameter?

Cheers

Callum

HectorMelendez-Alvarado

Callum,

This feature is meant to be leverage by developers in custom apps. If "Support Rollback On Failure" = True then as a developer you can toggle the "rollbackOnFailure" True or False when applying edits, the default is always True no matter what the "Support Rollback On Failure" setting says. So by default if any edit fails the entire transaction rolls back. If it wasn't like that then you could loose the uncommitted edits leaving your database in an inconsistent state. This is not the cause of your users not been able to update or delete features, that it is most like cause by data permission and table locks. You should check the ArcGIS Server logs for errors. Try this tool to query the GIS Server logs: System Log Parser

CallumSmith2

Thanks Hector

I am still experiencing this issue. Please see a extract from the log file:

I have no idea what is causing the issue. My feature service points to a non versioned feature class in a enterprise GDB. When I look at the layer properties via the rest api I see:

However I have another feature service pointing to another unversioned feature class in the same enterprise geodatabase that is working fine. When I look at the layer properties via the rest api I see:

As far as I can tell everything else is the same???

I am at a loss why I cannot update or edit my features via the feature service?

cheers

Callum

HectorMelendez-Alvarado

What version of ArcGIS Server are you using? What DBMS and version are you using. What geodatabase version are you using? Try the fallowing:

Start an edit session in ArcMap using the same mxd document that was use to publish the service. Take note of the database connection that the MXD is using (user account and geodatabase version).
Edit a record similar to what your users are doing in the web application. Save your edits.
If step 2 runs successful republish the service with a new name. In ArcGIS Server Manager take note of the Workspace that your new service is using and compare it with the original service.
Try to edit using the new service.
Post the screen captures of the Workspaces of your services and let me know how it goes.

CallumSmith2

Hi Hector

Yes I can edit and delete the features via the map document.

I republished like you suggested and I still cannot edit or delete via the new feature service.

Looking at the workspaces:

Original Service:

New Feature Service:

In terms of software our federated portal server environment id all 10.3.1. Our Enterprise GDB is hosted on SQL Server 2012 (SP1)

If you want to take this discussion offline you can email me on callum.smith@downer.co.nz

cheers

Callum

HectorMelendez-Alvarado

Is this a standalone layer or part of a relationshipclass, has attachments, participantes in topology, geometric network or archiving? Are you using OS or Database Authentication for your service? Can you post a screen capture of the Feature Class general properties?

I'm happy to continue to help but you should contact tecnical support, this might be a known issue.

In the meantime try an SDEINTERCEPT and a SQL trace of the feature service apply edit.

CallumSmith2

Thanks Hector

Yes I'm in discussions with the distributor here in NZ. So far we think it is something to do with the archiving? I will let you know how we get on and if/when we get to the bottom of it.

Cheers

Callum

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.