Manchmal erfordert das Projektdesign, dass wir Schemaänderungen an unserem übergeordneten Feature Layer vornehmen, und wir möchten sicherstellen, dass alle abhängigen View Layers dieselben Änderungen übernehmen. Dazu können gehören:<\/P>
Benutzer von ArcGIS Online (und<\/EM> ArcGIS Portal) können auf unerwartete Probleme stoßen, bei denen Aktualisierungen in ihren View Layers nicht angezeigt werden. Es ist wichtig zu verstehen, wie dieses Verhalten zu handhaben ist, bevor man den Inhalt komplett überarbeitet, alte View Layers löscht und neue von Grund auf neu erstellt.<\/P> <\/P>
„Feature Layers, die an View Layers mit Joins teilnehmen, können ihr Schema nicht ändern und sind immer schreibgeschützt und können nicht offline verwendet werden.“<\/BLOCKQUOTE><\/LI><\/UL>Sobald dies geklärt ist, arbeiten wir die Lösung in den folgenden zwei Szenarien durch, um das Problem einzugrenzen...<\/P>(Hinweis: Im Folgenden wird die Fehlerbehebung für View Layers behandelt, die mit der Schaltfläche "Create View Layer" auf der Detailseite des Feature Layer-Elements konfiguriert wurden.)<\/FONT><\/P> <\/P>
Sobald dies geklärt ist, arbeiten wir die Lösung in den folgenden zwei Szenarien durch, um das Problem einzugrenzen...<\/P>
(Hinweis: Im Folgenden wird die Fehlerbehebung für View Layers behandelt, die mit der Schaltfläche "Create View Layer" auf der Detailseite des Feature Layer-Elements konfiguriert wurden.)<\/FONT><\/P> <\/P>
Lösung: Wenn wir zuvor "Define an Area of Interest" für den View Layer gewählt haben... löschen Sie es.<\/P>
Beschränkung dokumentiert hier:
<\/span> <\/P> <\/P>
I was given this ENH number by ESRI tech support. I'll ask them to connect our organization to this request.
As mentioned above, please reach out to Esri technical support and ask to have your organisation connected to the enhancement request:
The Public Status for this enhancement is "in review" and as it currently stands, there are only two organisations attached to it.
Still nothing on this issue? Guess it's must too low on their priority list or they just can't fix it. maybe we just keep asking for the fix.
Ah okay @GlenShepherd that's more than fair! Wish the communication between countries was there for development but understandable!
Thanks for the codes!
Is there a database of all these enhancement requests or bug reports somewhere online to search? Or do I NEED to reach out to support to be able to get the information on them?
Sorry @RobertAnderson3 , as I work for the Australian distrubtor of Esri, I don't have visibility of how this functionality might be progressing at Esri Inc in the states. The only additional advice I could provide to anyone experiencing this behaviour is to reach out to your country's Esri Technical Support, describe how this issue is affecting your work and request that your case be attached to the following software issues:
I've added my support to the idea of removing the lock on layers with dependent joins. I've been working on dashboards to display Survey123 data for work orders, and in that I've needed the join for data being held in a repeat.
Took me longer than I'd like to admit to figure out the reason the survey wouldn't publish to add a field was because of the join I created..
Any idea if there's been progress on this?
Hello @MJBiazar .
I'm running into the same workflow you described above.
Hi @GlenShepherd and @erica_poisson ,
We published one of the Feature Layers in question in 2019, and I don't recall being prompted about anything regarding unique IDs. Reading about the Overwrite Web Layer tool here, I found a link to Assign layer IDs documentation which appears to only cover ArcGIS Pro 2.9. This may explain why this wasn't an issue when the layer was originally published (likely from 2.7 or 2.8).
Derek
@GlenShepherd @DerekMStrout -
I would be very interested in learning more about that setting and how it can be used/affects Overwrite operations where View layers are in use.
Also, @GlenShepherd - have there been any updates on the Esri end with regard to the broken/disconnected View issue I had posted questions about back in August 2021? I know some of the View experience was enhanced with the last release of AGOL, but I do not think this was addressed.
Thank you!
Hi @KennyLohr1 , thanks for your observations. I think my statement might have been hastily typed, so thanks again for holding me accountable. The inability to carry out an Overwrite operation from ArcGIS Pro is specific to hosted feature layers where a view layer has been created using a Join in the web portal.
That being said, there are other instances where we might see a failure to Overwrite (from ArcGIS Pro). I'm going to do some more testing and update this blog post soon.
But yes, you are right using that script or the or the ArcGIS Online "Update" button is essentially appending new records between tables with matching schema. Using an "Overwrite" publishing method is more suited to when we might need to make schema changes to an existing hosted feature layer, and depending on the changes (naming conventions, fields added/removed, domain edits, etc...) there can be quite a variety of flow-on effects if view layers have already been configured.
And thank you for the detailed troubleshooting @DerekMStrout , this is a setting I haven't looked into a lot with regards to this workflow but I'm going to check it out to update this post. I'd be curious to know how your feature layer was originally published prior to deciding to overwrite. Did you publish from ArcGIS Pro and get prompted to enable the assignment of numeric IDs initially?
Hi,
I wanted to follow up on my post from yesterday, as we were able to pinpoint the issue. And I was reminded that we ran into this a few weeks ago when overwriting a Feature Layer that had a public View that became invalid.
Someone can correct me, but it appears that the issue is the assignment of unique IDs to layers being published, which might be different than what the View layer is looking for from the original Feature Layer.
In both cases, our issue was solved from within the Configuration Parameters of the Overwrite Web Layer tool before overwriting/republishing, by unchecking the box to Ensure map is set to allow assignment of unique IDs (see attached). If this is checked (which it appears to be by default), and the map properties are NOT set to allow this assignment, then you will receive an error when Analyzing before overwriting.
The error message gives you to two options to rectify the situation: General Map Properties or Change Setting. When this problem first appeared, we chose the first option ("Change General Map Properties") and checked that box so that the map and the tool were in agreement. However, I think this is what caused the unique ID issue with the View layer. So our real solution was to choose the Change Setting option (of the Overwrite web layer tool) and uncheck the box.
We now plan to simply go to the Configuration Parameters and uncheck this each time we overwrite so as not to get the error or cause an issue with any View layers we've created.
Note that our workflows related to this issue are simple, with a single feature class being published as hosted Feature Layers with a single publicly-shared View layer. Other users will likely have more complex Feature Layers or Views that may require the assignment of Unique IDs, so this may not solve the issue for everyone.
Hope this helps!Derek
@GlenShepherd
This note caught my attention:
The reason this is interesting to me, is that we publish a number of hosted feature layers and I am considering whether or not we should switch to using feature layer views for consumption in applications. Your note suggests (or I could be misinterpreting) that if you publish a hosted feature layer using ArcGIS Pro, you can no longer update that hosted feature layer using ArcGIS Pro once layer views had been created from it. You did capitalize "Overwrite" and didn't use something more general like "update," so I am thinking this could be the important difference here.
The past couple of days I have been testing a publishing / update workflow suggested by this thread. I have combined this workflow with what seems to be a suggested practice of using view layers instead of feature layers in applications where the feature layer will be edited. I'm not sure if this is actually true, I may be inappropriately conflating "editing" with "updating" and/or "overwriting." At any rate, I published a feature layer; created feature layer views from it, then used the Python script in the linked thread to update the hosted feature layer using ArcGIS Pro. Maybe it was successful because this isn't explicitly an "Overwrite?" It's replacing the data in the hosted feature layer by truncating and loading in a FGDB feature class.
I think the takeaway is that while you may not be able to "overwrite" a feature layer using ArcGIS Pro once it has dependent layers, but that does not rule out being able to update the data in a different way using ArcGIS Pro, and that "updates must be carried out in the web portal" isn't necessarily true only because the more casual term "update" was used here. It doesn't appear based on my tests that creating feature layer views from a feature layer prevents one from being able to update/refresh the data in a feature layer and have that data flow through to the view layers. Would you care to comment on that?
My impression is that the "Overwrite" functionality in ArcGIS Pro is often used to update data, when only the data is changing...everything else like popups, symbology, etc...tend to be static. Overwriting everything every time seems to be having some unintended or complicating effects. Maybe "Overwrite" is like using a sledge hammer when only a small mallet is needed. Certainly, Overwrite is appropriate in the original use case where the schema changes; truncate and append does not work when schemas don't match. But I think for more routine updates where only the geometry and attributes are changing (my use case and possibly others) ...Overwrite might be the wrong tool to use.
Hi there @GlenShepherd, @MJBiazar, @JMitchell, @KevinMacLeodCAI, and @erica_poisson ,
We are experiencing a similar issue where after making only geometry and attribute updates to a FGDB, our overwrite of a hosted Feature Layer seems to have broken something with the View layer. The Feature Layer appears to contain all the updates, but the View layer contains zero features (displaying "Data Error" in the attributes table).
As this View layer is used in a public web app and is called by a custom widget, we'd like to preserve the item ID if possible.
And since we have successfully overwritten a similar hosted Feature Layer recently, using similar conditions (FGDB on same server, geometry and attribute updates only, etc.) and the publicly-shared View layer continued working as expected, we'd also like to find a solution that avoids the aforementioned parent FGDB download for future overwrites.
Thank you for any updates you may have found!Derek
Hi @MJBiazar ,
Sorry for the late reply. You mentioned "all views are working fine and still honoring the view layer definition queries"... Does the new field that you added still appear in the view layer?
My experience is a bit different.I've just published a layer, symbolised by a coded value domain and created a view layer from it in ArcGIS Online, with a definition query that filters the field it is symbolised with.
I then opened ArcGIS Pro (2.9) again, added a couple more fields, added some more features and carried out an Overwrite.The existing view layer fields still maintain the "inherited" property, however it has not inherited any of the new fields added to the parent and all features are missing, with "Data Error" under the attribute table.
Perhaps it only works if you overwrite with a downloaded FGDB of the parent rather than the original feature class? Strange one.
Hi @GlenShepherd ,
Thanks for sharing this helpful guide. I've done some testing and it seems like having view layers (not joined views) won't affect the ability to overwrite a hosted feature layer.
I was able to successfully overwrite a sample hosted feature layer on ArcGIS Online despite having multiple view layers with different types of view definitions.
After creating views, I downloaded the hosted feature layer as an FGDB, opened in Pro, added new features, added new field, edited existing attributes for the existing feature and overwrote the hosted layer. All views are working fine and still honoring the view layer definition queries.
However, if you have a view created from Join Feature tool, you won't be able to overwrite your hosted feature layer receiving a 400 error:
ERROR: code:400, Unable to delete item. This service item has a related Service item, Bad syntax in request.
I would appreciate it if you could confirm this behavior on your end too. Best,
MJ
@GlenShepherd Thanks, left a kudos for that idea!
@GlenShepherd @JMitchell nice, I just +1'd
Hi @JMitchell ,
I had a look around and looks like there is a relatively new(ish) Idea submitted for this functionality: https://community.esri.com/t5/arcgis-dashboards-ideas/allow-adding-fields-to-agol-hosted-layer-with/idi-p/931440
Definitely be sure to flick a 'Kudos' on that one... @KevinMacLeodCAI might like to as well. The suggestion for 'suspend' and 'refresh' functionality on a view layer join would be pretty cool to have.
Is there an existing idea or somewhere that I could put my vote behind what @KevinMacLeodCAI suggested regarding getting rid of the locking of the parent when joins are used in a view?I came across this blog post while looking into why having views for a layer locked the schema of the parent; now I know that that is only the case with views using joins (which is the main reason I utilize views).I am using several views with joins to help symbolize and label a feature layer with several related tables as I do field data collection within field maps. I need to add several new fields in one of the related tables, but in order to do that I now have to get rid of the various view layers to make that seemingly simple change and thus have to spend time recreating the views, the associated label and symbology for each of those view layers and adding them back into my map.
Thanks,
I did create a new idea - https://community.esri.com/t5/arcgis-online-ideas/offer-official-support-for-removing-related-tables/idi-p/1088567/jump-to/first-unread-message
Thanks for your help around this issue. I would definitely love to see some improvements made so this is officially supported someday!
Erica
Hi @erica_poisson ,
Sorry to reply weeks later. Did you end up working with technical support again on this behaviour at all? Any outcome?
Not sure about the new experience in future updates and whether this will be incorporated, but I think you have a pretty strong use-case for submitting an ArcGIS Idea through this domain. I'll certainly give it an up-vote if you do.
Hi @GlenShepherd
I did as you suggested w/ the following results:
It seems like this modification just breaks the View's connection back to it's parent hosted feature layer. The weird part is, one of my problem layers (which doesn't have the new field) has not gone through the process to edit the REST definition....
For that layer I checked all fields for "properties: inherited" (they were), removed the AOI, removed the View Definition Filter, removed custom symbology and none of that made the missing field appear.
I feel like my only solution is to re-create the Views.
Thank you for your help. I might connect with technical support again. Ultimately, I feel like if I want to remove related tables in the future, I need to ensure the schema/pop-ups are 100% configured before doing so.
One final question though...at the UC this week, it seemed like the View creation experience will be changing in the future. Will removal of related tables be supported in the new experience? Or will the workflow through REST still need to be used? It would be really great it for public Views a related table could be removed/hidden in some sort of officially supported way. In my example here, our related table tracks unauthorized trail use (e.g. ATVs, vandalism, etc.). This is for internal use only, so we remove the related table from the public View of our trail data inventory.
I've read the bug you mentioned and as this is defective behaviour attributed to JSON edits without any currently known workaround, I'm sorry there's not much I can help with regarding the pop-ups. As for your case, I work for the Australian branch of Esri and don't have access to casework from other countries unfortunately.
It's certainly curious behaviour that you're describing.
Some troubleshooting suggestions:
Being that there are a lot of moving parts to your workflow (i.e. updated hosted feature layer, six views, related tables, JSON edits) it would be quite difficult to diagnose over discussion board comments. I'd reach out to technical support again and outline everything that has been carried out with this content and/or allow them access to your organisation to take a look at the items' Settings.
You can email me as well if you like.
1. I am saying that the new field is not in my attribute table and also cannot be found under "Define Fields" when configuring the View Definition. Oddly enough, the new domains (for other fields) did show up when I followed your steps above for resetting the fields to the source.
2. Yes, I mean that I am unable to "configure pop-up" at all for the View layers that went through the workflow I described in my initial post (point 2). This is what I see now - it basically locks up the View "Visualization" page and I need to refresh or change pages to 'unlock' it again. If I click "OK" or "Cancel" at the bottom, nothing happens.
As I mentioned above, I did open a technical support case for this issue and we logged #BUG-000136618. This was done via case number #02707008.
I mentioned that 3 of my Views do not show my new field as an option under "Define Fields" under the View Definition. Two of these Views went through the process to hide/remove the related table, while one did not. So, it seems like I am having an issue with a one "regular view" that I did not do anything strange with, and then also with my 2 "modified views" where I have removed the related table.
I do have another "modified view" (where I removed/hid the related table) that does show the new field.
It makes no sense. Do you recommend I open another technical support case?
1. Are you saying that these view layers do have the new field in their attribute table but you are only unable to see it in the 'Define Fields' list?
2. Do you mean you're now unable to use the "configure popup" option as described here: https://support.esri.com/en/technical-article/000022958 ?
The following document describes what supported schema changes we can make to the JSON of an item via the REST endpoint: https://www.esri.com/arcgis-blog/wp-content/uploads/2014/10/How-to-Update-Hosted-Feature-Service-Schemas1.pdf?rmedium=bulk-arcgis-files&rsource=http://blogs.esri.com/esri/arcgis/files/2014/10/How-to-Update-Hosted-Feature-Service-Schemas1.pdf
Unfortunately, this does not include re-ordering the fields of an item and understandably for a view layer, this would likely break the relationship with the parent hosted feature layer...
Following up from removing/hiding the related table, did you open a new case with Esri Technical Support for this issue?
I've got two questions about this:
1) for your Scenario #1 above, can it take some time for a new field to show up in the Fields view definition for a layer?
I've added a new field to my hosted feature layer. There are 6 different Views created from this. 3 out of 6 of these Views had the new field in the "Fields" list when I went to modify the View definition. The other 3 did not; these 3 did have an AOI defined, so I removed that, but the new field still does not show up in the Fields view definition list. Any thoughts?
2) I used the workflow described below to remove/hide the related table from my View layer which resulted in this bug - #BUG-000136618.
The solution was provided to me by Esri Customer Care (see below for more details). Now, I am unable to edit my pop-up. Deleting the View in question is not an option because it is used in almost 100 maps. Is there some sort of work around that would allow me to a) edit the pop-up or b) re-order fields?
From Esri Customer Care:
Go to the admin rest endpoint of your hosted view layer and used the delete from definition tool. We added in the following snippet of json:
Once done the hosted view layer no longer shows the related table.
Any help would be appreciated,
@GlenShepherd thanks for your response to @MattHuser's question. I was just bumping into the same issue myself. I need to add features classes to a published feature layer that have views built from it, and was investigating why the new feature classes weren't showing up in the view, which led me to this blog & comments/posts.
Sounds like the views need to be recreated each time that new feature classes are added, and swapped out in the map in order to update the apps. Is that correct?
I'm also willing to supply use cases if needed - thanks!
@GlenShepherd Thank you for the explanation and submitting a bug/enhancement on our behalf! If you need client use cases, I would be happy to explain why this is needed and what additional steps we have to take as a workaround to "support" this grey area. Feel free to reach out!
Hi @MattHuser ,
Apologies for the delayed response, are you still trying to work with this issue?I've just been testing and confirming the behaviour in ArcGIS Online. Unfortunately, we're looking at a current limitation of the 'Overwrite' method for updating an existing hosted feature layer with pre-configured view layers and a bit of a grey area between the 'overwrite' and 'append' methods for updating our GIS data.
If we're adding feature classes to feature layer during an overwrite, these new feature classes will only appear in subsequent view layers built after the overwrite has been carried out. Meaning that we would need to re-configure new view layers to see the newly added layers.
If we're appending new records to an existing layer within the hosted feature layer (via the 'Update Data' option in ArcGIS Online), then we would see new feature layers within the views "as soon as updates are applied" - Documentation: https://doc.arcgis.com/en/arcgis-online/manage-data/manage-hosted-feature-layers.htm#APPEND
But unfortunately, the 'Append' method can't be used to add new feature classes into a grouped feature layer. Hence, the "grey area" I mentioned...I've submitted a bug and enhancement for this behaviour:
Hopefully future development efforts can address this behaviour.
We originally started out with a FGDB in our local environment then uploaded it to our AGOL. That created one hosted feature layer that contains many feature classes. We've then created hosted feature layer views off of it.
When we added a new feature class to our FGDB and then used the python code below to migrate the changes to AGOL for the existing hosted feature layer, the hosted layer views do not inherit the new feature class that was added.
fgdb = gis.content.get('xyz')print ("Updating database:",fgdb.title)fgdb.update({}, theFGDBZip)fgdb.publish(overwrite=True)
I'm happy to take this conversation offline and I can demonstrate what we are seeing if that is easier. Just let me know the best way to coordinate with you. Appreciate the help!
Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registrieren Sie ein kostenloses Konto.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
