Getting Object has no Schema locks Error while trying to create new feature, after Subnetwork Update through REST API GP Service

299
7
08-12-2022 03:00 AM
MohammedHilal_K
New Contributor II

Hi,

I was trying to create an Add-Inn to update the subnetworks through REST API GP Service, because it is very fast compare to the inbuild tool in ArcGIS Pro. For testing purpose I used REST API GP Service directly, the process got success in my branch version. But after the update When I Try to create a feature in current branch version, am getting 'Object has no schema locks' Error. Sometimes I could solve that by switching the branch versions, but sometimes not. 

Any suggestions should be appreciated. 

0 Kudos
7 Replies
RichRuh
Esri Regular Contributor

Branch versioning does not support multiple concurrent editors against a single version. When you are updating a subnetwork with a direct REST call it's creating a second editing session. That's the source of the schema lock errors.

Have you tried using the Pro SDK to update the subnetworks rather than REST?

 

0 Kudos
MohammedHilal_K
New Contributor II

HI Rich,

I tried Pro SDK and it is taking about 10 minutes to updates the subnetwork, but when I tried with REST call, it is taking only less than one minute. Is there any way to solve the Schema locks error? 

0 Kudos
RichRuh
Esri Regular Contributor

The time difference here is alarming and unexpected.  Do you have fiddler installed? I'm wondering if you could examine the call to update subnetwork that is generated by the Pro SDK and see if it matches what happens when you manually call it?  Is the Pro SDK updating multiple subnetworks?

--Rich

0 Kudos
MohammedHilal_K
New Contributor II

Hi Rich,
Both the REST call and ArcPro SDK is doing the same work, like updating multiple subnetworks. REST call is super fast taking about 1 minute. while ArcPro SDK taking about 8 to 10 minutes to update the subnetwork on first time. Second time the processing time is decreasing to 3 to 4 minutes. That's why I'm focusing to the REST call. 
Also I noticed that if we are updating subnetwork for branch version from SDE.Default, not getting any schema locks error. But My task is to update the current branch version.  Is there any idea that can add in to the Add-Inns,  like switching the versions before and after updating the subnetwork?  

0 Kudos
RichRuh
Esri Regular Contributor
Both the REST call and ArcPro SDK is doing the same work, like updating multiple subnetworks. REST call is super fast taking about 1 minute. while ArcPro SDK taking about 8 to 10 minutes to update the subnetwork on first time. Second time the processing time is decreasing to 3 to 4 minutes. That's why I'm focusing to the REST call. 

When you call the Pro SDK to update a subnetwork, how long does the REST call take?

Also I noticed that if we are updating subnetwork for branch version from SDE.Default

I'm not sure what you mean here. Are you updating the subnetwork on the branch version or the default version?

0 Kudos
MohammedHilal_K
New Contributor II

In ArcPro SDK, I tried utilitynetwork.subnetworkmanager.UpdateAllSubnetworks (tierName,true), which is takes 8 to 10 minutes. Which is working fine and there is no schema locks error. 

Second case, I directly call the REST API through URL(like '......../UtilityNetworkServer/updateSubnetwork') to updates the subnetwork. After this am getting schema locks error while trying to edit the current version features. if I can resolve this i will call this REST API though and Add-Inn. 

One observation is that when we update subnetwork of a branch version by standing in default version, after updation switching back to the branch version and trying to edit the features is working without any schema errors. But my requirement is that if we click a button, the current branch versions subnetworks should be update. 
Any help?

0 Kudos
RichRuh
Esri Regular Contributor

The schema locks error is expected. When you edit a version by calling the REST endpoint, it creates a write lock, since only one connection can be editing at a time. 

What I am trying to understand is why it takes so long to call update all subnetworks from the SDK. If we can fix that problem then you'll be able to use the SDK instead of the REST endpoint, and the schema locks problem will be solved.

--Ric

0 Kudos