Latest Contributions by MelanieWawryk

This is still happening but not always from a 10.8.1 oracle geodatabase service uploaded to AGOL from ArcMap. We have lots of standard fields with the same name (CATEGORY, SUBCATEGORY, COVER_SHAPE, STATUS, OWNERSHIP etc) that have different domains and most of the time there is no issue, however, it is still cropping up as an error occasionally. We are editing the layer on the geodatabase through Field Maps and Collector where the error prevents the layer from loading. The error does not happen in Collector Classic. It would be great if the next update to Collector and Field Maps could ignore this issue. It is entirely reasonable for fields with the same name to have different domains across a geodatabase so that condition should not cause an error that prevents a layer from loading. ... View more

Thank you, I'm in Canada and you saved a ton of back and forth of trying to replicate the issue locally prior to it being sent to the Esri Inc AGO server team. Hopefully, this will satisfy local support to allow it to move forward. ... View more

@Anonymous User Could you look at the error below please? I believe the error points to a problem on the AGOL cloud servers, likely  an indexing issue. It has since been fixed with no intervention on our side. If you look at the error it points to a host not finding the key (the survey). The host is given by the HostID and that host is one of Esri Inc cloud hosts. This message would come up 25% of the time, the rest of the time the survey came up and was fully functional. If the servers are load-balanced it would explain why it would work 75% of the time. Please take a look at the error and confirm that you would interpret it the same way? We had a similar thing happen about 5 years ago with open data, it took ages to get to Esri inc and in the end, it was an indexing issue on the cloud side, it was manually reindexed and it was fine.  I just need confirmation on what the error means so we can document the outage. Thanks ... View more

I suspect it might be an indexing issue on one of the host cloud servers, it seems the error can't find the survey (the key). I would assume more than one server serves up these services and is load balanced so a poor index on one server would explain the intermittent issue but not why some people can not get to it at all.   When I look at the incoming data between midnight and 1:30 pm today we are at 483 screenings and yesterday same time frame was 642 so for sure we are missing people but about three-quarters are able to get to the survey. Very strange and frustrating.    ... View more

We started experiencing the same type of thing today. It is intermittent and only on some devices but the devices are random so iOS and some Android devices work, others don't, some work some times others not at all. We are using Survey123 Connect V3.11.123 on a feature service on AGOL but using a 10.8.1 oracle geodatabase in the feature service. feature service and survey are public. I have a support call in and will post if they find a solution.  ... View more

We also have this issue and update most of our layers daily through ArcPro and a python script. Manually unsharing and then sharing them seems to resolve the issue. I will try to add and unshare followed by a share into the script. ... View more

It is also happening with oracle but not all the time. We have 122 Open data layers that we export daily through Pro/Python script run through a windows batch file. All but a handful of them work and previous to a week ago all have worked. We have run in to this before but could manually run overwrite the webservice out of ArcPro but now we get the fairly useless ERROR 999999: message even when manually trying to update the hosted features. The other 118 still work both manually and through the script. The log gives no extra information. We are using: Windows server 2012 R2 ArcPro 2.5 Oracle 12C ArcGIS 10.7 geodatabase We have done all the suggestions from all posts I could find (see below). Most suggestions also assume that it hasn't been working for months before suddenly getting this error. Works fine on roughly 118 or 122 hosted services that are updated through same method/script Has worked for months all arcpro documents are in same folder location on the local machine data all from same geodatabase, same db owner Connected as database owner same AGOL user and hosted folder, share setting etc  tried to a new hosted layer - no luck have pro pointing to local directories for it's processing rebooted machine Lots of room on local comuter tried coping layers to new map > no luck deleted temp files file path is not too long, working ones have longer names plus it worked previously No analyze errors Also checked geometry checked symbology No new domains No relationship classes feature class size, one Display field in Pro is valid using default python environment in Pro Used fiddler while trying to publish. Nothing pops out  SDDraft is created in: C:\Users\<username>\AppData\Local\ESRI\ArcGISPro\Staging\My Hosted Services (NAME) Possible problem with creating index (no log.txt in Maps>index>LAYER folder) > rebuilt indexes > no change Missing  publishingResults.json in C:\Users\<username>\AppData\Local\ESRI\ArcGISPro\Staging\SharingProcesses\<Job ID>\ and found missing the publishingResults.json  Is it actually failing on Consolidate data?  vs Staging is set to E:\ArcGISPro\Staging\SharingProcess but it is putting it in  C:\Users\adminsde\AppData\Local\ESRI\ArcGISPro\Staging\SharingProcesses It would be nice if Esri would add all of these checks and what ever else is making it fail to the analyze tool so we can understand what the issue is or give better error messages when things don't work. Any other suggestions of what to try are welcome. ... View more

I totally agree. We were using tracking layers for several apps only to have to apologize to staff that they no longer work. Worse still what is supposed to be replaced with doesn't really exist outside of demos at conferences. On top of that we are on an ELA so have to purchase tracker up until the end of our ELA and then negotiate to have it included in the renewal. It is great that Esri has ELAs but what is the point if they randomly remove functionality and them make you pay for a re-imagined version of what we just lost. I would be happy to pay for something new that I need but in this case what was offered worked for us and now we are being asked to pay for functionality we don't need and complexity we don't want (if we use the enterprise version portal/data store/track viewer). We had a simple workflow: tracks are created as a tracking layer in AGOL daily and them imported each night in to our geodatabase. Yearly tracks are removed from AGOL. Very simple, users only need to use one app. Is there any documentation comparing functionality, restrictions, costs and data model of Tracker for AGOL vs Tracker for Portal? We have several questions about how to export the tracks to our current geodatabase layer and how easy it is to truncate the tracks from AGOL or Portal periodically.  The way the tracking layer was removed and tracker was released was very poorly executed.  ... View more

Charging extra for tracker is total BS. We are long time Esri users on on a ELA. We were using tracking in ArcCollector just fine up to the new version which doesn't support it anymore. Tracker has not automatically been included in our ELA so we have to wait to negotiate it the next time we renew or purchase outside the ELA? What is the point of an ELA when working functionality is replaced with something that is not included. Same thing happened with ArcGIS Monitor except it's pricing is hugely out of whack. It's a great product but most of us GIS types just want to monitor our services with it and not use it as a network monitoring solution which it is priced as. Esri has increased the complexity of the servers with portal and have taken away the piece to monitor it with. So frustrating. ... View more