Feature Layer Overwrite Error - Data Referring to Another Service

8918
13
10-07-2015 02:28 PM
CodyYates
New Contributor

I've been experiencing the following error for a few months now every time I try to overwrite my feature layer in order to update my Web Mapping Application that was built with the Web App Builder:

"User cant overwrite this service, using this data, as this data is already referring to another service."

My map is set up like this:

  • I uploaded a file geodatabase which created a feature layer.
  • I added the feature layer to a map, created symbology, and saved the layer and map.
  • I then create a Web Mapping Application by using the Web App Builder that pointed to the previously made Web Map and published it.

I'm unsure of how to update this map. I assumed I could just overwrite the feature layer with the updated file geodatabase, but I get that error each time and I'm not entirely sure what it means. I'm guessing that it can't update the layer while the Web Mapping Application still references it, but if that's the case, then how are you supposed to update the map?

I've been forced to just create a whole new layer each time and redo all of the symbology. There must be a better way to update a web map.

13 Replies
ConradSchaefer__DOIT_
New Contributor III

We ran into another issue related to this error.

Turns out the gis.content.search portion of the blog post is not formed well if you have similarly named files. We had an older version named ElectedOfficials.sd and a newer version named Elected_Officials.sd. Using the blog post search query gis.content.search(“{} AND owner:{}”.format(sd_fs_name, user), item_type=”Service Definition”)[0] you take the zeroith index result under the assumption it is the correct object (and possibly the only object returned??). For our search however there were two items returned. The search formed as follows "Elected_Officials.sd AND owner:[edited out]" yielded two results. It returned both ElectedOfficals.sd and Elected_Officials.sd in that order so the zeroth was the wrong one. We revised the query string to be "title:{} AND owner:{}" and it will yield only one result. We have added a check for the length of the query return to avoid future run-ins with this issue should other similarly yet NOT identical file names be located in our account.

We first caught on to this when we burrowed down into the class dictionaries to look for dependencies. When I transferred the ElectedOfficials.sd out of my accounts ownership it no longer met the blog posts query requirements and the Elected_Officials.sd moved to the zeroith index and exposed the issue.

The builtin .__dict__ can be quite useful!

0 Kudos
SteveScott
New Contributor III

This error came up after I renamed my file with underscores instead of spaces. Then I changed it back and I still have the error. I broke my app. Unlike other users I specified the owner and title and only came back with one search result.

0 Kudos
DrewDowling
Occasional Contributor III

In my case the problem wasn't with the search results, I was getting the correct service definition item, my problem was that the map item name had changed in the Pro .aprx. Since the target feature service titles no longer matched the update call would fail.

https://gis.stackexchange.com/questions/309685/how-to-update-a-hosted-feature-service-on-arcgis-onli...

I deleted and republish the feature serive from Pro the thread I found the solution on says you can also change the map name back to the original name. I didn't try this.

0 Kudos
StephanieBosits
New Contributor III

Has anyone found any other solutions to this? My issue is definitely not based on getting the incorrect item in my search as I am using a content.get on the item id instead of the search. It also works fine with a manual overwrite from Pro. I have tried changing the layer name when publishing and that doesn't seem to help or hurt the situation.