Feature Layer Views: Updating Parent Feature Layer Schema

9387
32
05-02-2021 11:51 PM
GlenShepherd
Esri Contributor
12 32 9,387

The Premise:

When we create a Hosted Feature Layer View (hereafter referred to as a "View Layer") from our Hosted Feature Layer in ArcGIS Online, our View Layer schema is inherited from its parent Feature Layer.

Sometimes project design requires us to make schema changes to our parent Feature Layer and we want to be able to ensure that all dependent View Layers are inheriting the same changes. These might include:

  • Adding or deleting fields
  • Updating coded domain lists
  • Editing field name aliases

ArcGIS Online (and ArcGIS Portal) users may run into unexpected issues where updates are not being reflected in their View layers. And it is important to understand how to manage this behaviour before overhauling the content, deleting the old view layers and creating new ones from scratch.

 

The Troubleshooting:

There are a few reasons why our View Layers might not be inheriting schema changes made to the parent Feature Layer and a few troubleshooting methods at our disposal to narrow down the cause of the disconnect...

First of all, we want to ensure that we're not trying to do something that is simply not possible in ArcGIS Online. View layers that participate in table Joins performed through Map Viewer will create schema-locks that prevent the parent Feature Layer's schema from being edited. We can read more about this here: Bring your data closer together: Save analysis results from Join Features as Hosted Feature Layer Vi...

  • "feature layers that participate in view layers with joins cannot have their schema altered and are always read-only and cannot be used offline."

Once we've clarified that. Let's work through the solution in the following two scenarios to narrow the issue down...

(Note: The following will cover troubleshooting View Layers that have been configured using the "Create View Layer" button on the Feature Layer's Item Details page.)

 

Scenario 1: We've added new fields to the parent Feature Layer but cannot see them in the View Layer's attribute table

Solution: Update "Define Fields" for the View Layer

  • For the View Layer item, go to: Item Details > 'Visualisation' tab
  • Click the View Layer's 'More Options' list and go to: Set View Definition > Define Fields
  • Check the boxes next to the newly added fields at the bottom of the list.

Resource: Problem: Hosted feature view does not inherit new field added to hosted feature service

Solution: If we have previously chosen to "Define an Area of Interest" for the View Layer... Delete it.

  • For the View Layer item, go to: Item Details > 'Visualisation' tab
  • Click the View Layer's 'More Options' list and go to: Set View Definition > Define an Area of Interest
  • Click "REMOVE AREA" 

Limitation documented here: Considerations when creating hosted feature layer views

viewDef.png 

 

Scenario 2: We've added new domains to the 'List of Values' in a particular field for our parent Feature Layer and cannot see them being inherited by a View Layer

Solution: clicking on the "Reset to source" button to revert the view layer's field update property from "Overridden" to "Inherited".

  • This disconnect may have occurred due to changes being made to specific fields within the View Layer, causing the field properties to change from "Inherited" (from the parent layer) to "Overridden".
  • The simplest way this occurs is if changes are made to field names. This causes a break between the aliases in the parent table and those in the View Layer table.
  • For example:
    By default, changes made to the parent layer are "Inherited" by the view layer. Properties: Inherited
    Inherited.png

  • However, if a change is made to the field name, the view layer's update property becomes "Overridden" and changes to the parent hosted feature layer are not reflected. Properties: Overridden
    Overridden.png
  • The connection and inheritance can be re-established by clicking on the "Reset to source" button (pictured above) which will revert any changes made to the field, back to that of the parent Feature Layer. The user should check all other fields to ensure this hasn't happened elsewhere.

Read more about the Settings that influence the "Inherited"/"Overridden" field property on View Layers here: Hosted feature layer view settings (edit, courtesy @Bnewell).

Note: In some cases, users will need to carry out a combination of the solutions outlined above to resolve all inheritance issues they are encountering.

 

Some key things to remember:

  • To maintain schema inheritance, it's best not to make edits in the 'Data' > 'Fields' tab for your View Layers.
  • Once we have published our Feature Layer and created View Layers from it using a Join, we cannot use ArcGIS Pro to Overwrite the parent Feature Layer, as it is now schema-locked. The View Layer(s) will need to be deleted first.
  • If we have subtypes and domains configured for a feature layer and symbology/filters dependent on this schema; create all templates for your layers in ArcGIS Pro prior to publishing.
  • If we have a View Layer participating in a table Join, and we want to edit the parent Feature Layer's schema, then we will need to delete the View Layer created from the Join operation.

 

32 Comments
KevinMacLeodCAI
Occasional Contributor II

Useful guide, thank you Glen for the post.

 

Sidenote enhancement idea- It would be an excellent if in a future update if joins did not lock out parent hosted feature layers. This prevents data from being able to be updated. Let's say you have Parcels. And a read-only view of Parcels joined to something. Well what if you wanted to have a notebook update the Parcels weekly. This prevents that. It would be useful if joins did not create this kind of a lock and increase the amount customer utilization of hosted feature layers.

 

 

MattHuser
New Contributor II

@GlenShepherd What about adding a new feature class or table to the overall schema? For example, our original source of the hosted feature layer is a FGDB, we continually use the "update" process to push updates from our local environment to AGOL. But when we add a new feature class to the FGDB and use the "update" process, the parent (hosted feature layer) is updated to include that new feature class but none of the hosted views inherit the new layer.  Is there something we have trigger to force a schema inheritance of a new feature class?

GlenShepherd
Esri Contributor

Hi @KevinMacLeodCAI ,

Thank you, we're certainly in agreement on that sidenote. There are currently enhancement requests and defect records lodged for this behaviour, so fingers crossed 🤞

Hi @MattHuser ,

Can you elaborate on your hosted feature layer; is this a series of feature classes grouped into a single feature layer and you are updating records within them? Or are we adding a completely new feature class to the grouped layer?
How is your update method carried out?

KevinMacLeodCAI
Occasional Contributor II

Thanks Glen for your vote of support! I know it would be huge and increase adoption and use cases for many Orgs.

TomThomey
New Contributor

.

MattHuser
New Contributor II

Hi @GlenShepherd ,

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('XXXXXX')
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!

 

GlenShepherd
Esri Contributor

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:

  • ENH-000141026 - "ArcGIS Online: add ability for the 'Update Data' method of appending to add additional feature classes to a grouped hosted feature layer."
  • BUG-000141027 - "ArcGIS Online: If the "Overwrite" method is used to add new feature classes to an existing hosted feature layer, any pre-configured view layers will not inherit the newly grouped feature classes"

Hopefully future development efforts can address this behaviour.

MattHuser
New Contributor II

@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!

ADHSGIS_Admin
New Contributor

@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!

erica_poisson
Occasional Contributor III

Hi @GlenShepherd 

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:

  • {
    "layers": [{
    "id": 1,
    "relationships": [{
    "id": 0
    }]
    }]
    }

Once done the hosted view layer no longer shows the related table.

Any help would be appreciated,

GlenShepherd
Esri Contributor

Hi @erica_poisson ,

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-Sch...

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?

erica_poisson
Occasional Contributor III

Hi @GlenShepherd 

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. 

erica_tefft_0-1626182793288.png

 

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?

 

GlenShepherd
Esri Contributor

Hi @erica_poisson ,

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:

  • Go through all the fields in the troublesome view layers and check for the "properties: overridden" message mentioned in 'Scenario 2' above
  • Reverse the remove/hide related table changes that you made.
  • Double-check that the AOIs have been deleted
  • Publish a new test copy of your parent hosted feature layer and go through all the same steps to create your view layers to try and track where the disconnect occurred.
  • Think about what has been done to those 3 view layers at any point in your workflow and strip back those changes (where possible) to see what might've broken the inheritance...

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.

erica_poisson
Occasional Contributor III

Hi @GlenShepherd 

I did as you suggested w/ the following results:

  • Checked all "properties: overridden" and ensured that all fields showed as "properties: inherited", which they did. 
  • Created a new test view from the original hosted feature layer. All fields were present as they should be. 
  • Used the "Delete from Definition" tool at REST to remove the related table. Once done, all fields were still present, but I couldn't update the pop-up (which was expected). 
  • Attempted to undo my removal of the related table using the same code snippet as above (I wasn't sure what else to use) through the Add to Definition and Update Definition tools at REST. Neither worked - I received an error in both instances. I am not sure if I needed a different code snippet...

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. 

GlenShepherd
Esri Contributor

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.

erica_poisson
Occasional Contributor III

Hi @GlenShepherd ,

I did create a new idea - https://community.esri.com/t5/arcgis-online-ideas/offer-official-support-for-removing-related-tables...

Thanks for your help around this issue. I would definitely love to see some improvements made so this is officially supported someday!

Erica 

JMitchell
New Contributor III

Hi @GlenShepherd ,

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,

GlenShepherd
Esri Contributor

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/...

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.

KevinMacLeodCAI
Occasional Contributor II

@GlenShepherd   @JMitchell nice, I just +1'd

JMitchell
New Contributor III

@GlenShepherd Thanks, left a kudos for that idea!

MJBiazar
Esri Contributor

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
Esri Contributor

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.

DerekMStrout
Occasional Contributor

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

KennyLohr1
New Contributor II

@GlenShepherd 

This note caught my attention:

  • Once we have published our Feature Layer and created View Layers from it, we cannot use ArcGIS Pro to Overwrite the parent Feature Layer, as it now has dependent layers. Either the View Layers will need to be deleted first or the updates must be carried out in the web portal.

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.  

DerekMStrout
Occasional Contributor

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

OverwriteWebLayer.png

OverwriteWebLayerError.png

GlenShepherd
Esri Contributor

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?

erica_poisson
Occasional Contributor III

@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!

DerekMStrout
Occasional Contributor

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

DianaKalil
Esri Contributor

Hello @MJBiazar .

I'm running into the same workflow you described above.

 

 

RobertAnderson3
MVP Regular Contributor

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?

GlenShepherd
Esri Contributor

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:

  • ENH-000155159
  • BUG-000134903

 

 

RobertAnderson3
MVP Regular Contributor

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?

About the Author
Esri Australia Client Success team member