nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Provide visual cue if field edits will apply to Project or source data

RTPL_AU

These days, as at Pro 3.5.2, Catalog is still incorporated within Pro.

Tasks that, in ArcMap were separate, are now also done in the same dialog window such as editing feature class schema.

I never quite seem to get it right to make permanent changes permanent, and project only edits stick to the project.

Aliases is the big one. I often want to have aliases for use in imbedded tables in Layouts. These changes must not be carried over to the main dataset and end up appearing everywhere else.

I understand that the key is where you initiate the edit from - Catalog or from within the Map Contents, but it still doesn't play nice when you least expect it.

Also - when you initiate an edit from within the map to change an alias but end up adding a field to do symbology things with: What ends up getting saved where? The field is permanent but the alias not? Except when it is, but not when you don't want it to? Over the last decade I've found the behaviour to be inconsistent.

Idea:

Provide a visual indicator in the Edit Fields window to clearly indicate what is/will be saved into the Project and what is/will be saved to the source feature class.

Find more posts tagged with

Geodatabase

Status: Open

Comments

Valeria Chavez

Hi @RTPL_AU! I'm hoping to get some clarification here. What I understand here is that you would like there to be an indicator on the Fields view to differentiate between the layer and the data source. There is already a drop-down with this information available:

I think part of the confusion is coming from a distinction between the layer and the data source and what properties apply to each. This is documented on the "Field properties" section of the documentation.

I also made an ArcGIS Pro Short about this, available here, that might provide some extra info.

I might be misreading your Idea though. If you could expand a bit more on what you're hoping to see, I would greatly appreciate it!

RTPL_AU

@ValeriaChavez
Sort of, but the behaviour when the layer name is shown is not quite consistent with the intent you are alluding to.

Current behaviour is more akin to "Data Source" will edit data source only. "Layer Name" can save to project and data source.

With the layer name displayed you can still add and rename fields that will then be applied to the data source.
If you add a field and rename another Alias with the layer name shown, the additional field is saved to the data source but the alias is saved to the project.

If you rename a field and its Alias, with the layer name shown, the data source is updated with the new field name but the Alias is only saved to the Project.

This Idea is to make it clearer to show what is saved where under all conditions.

SSWoodward

Moving this back to open.

This idea makes sense and I understand where the confusion comes from.

We do not block users from making schema changes to their data source, like adding fields, when viewing a layer's fields view. When adding a field in the layer's fields view, all configurations that can be set uniquely on a layer, like alias and display settings, are saved with the layer and only the settings that are required to define the field in the database are added to the data source.

In the examples with aliases that are describe below, all cases are consistent with the fact that you cannot alter the data source alias from the fields view of a layer. A field in a class may be referenced by multiple layers and have a unique alias in each. A fields name, or the presence of a field in the data, cannot change depending on the layer and so must be propagated to the data source.

It is a reasonable request for a UI that more efficiently communicates these differences without the need for prior understanding of the layer/class distinction.