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; } } }

Allow users of the Split tool to override the split policy on domains at time of use.

RTPL_AU

The default Domain behaviour in Pro 3.3.2 when using the split tool on a feature that has fields with Domains is the result has the content of the fields empty (or the domain default code).

Please change the dialog of the Split tool to indicate what the Domains are set to and provide a way to override.

Encuentra más publicaciones etiquetadas con

Editing

Status: Abrir

Comentarios

Scott_Harris

@RTPL_AU What is the Split Policy on the domain within the geodatabase? If it's set to "Default" and the default value for the field with the domain is null, that is what the Split tool will honor.

Check first in the Domains view:

To see what "Default" means for that field, check in the Fields view:

You may want to set the Split Policy on that domain to "Duplicate" or you may want to keep it as "Default" but update the default value of a given field.

RTPL_AU

@Scott_Harris Of course...

Idea changed to request new functionality in Split tool dialog to provide override of Domain setting.

It is not ideal to change the domain settings every time an edit session is opened so it is better to have an option at the tool level to override the domain setting.

Bonus points to rename "Default" in the Domain properties to something a bit more descriptive and to prevent confusion, as the word 'Default' does not clearly indicate what the actual default value will be.

Scott_Harris

Thanks for confirming the issue further @RTPL_AU . I'll re-open the Idea.

joyoung_kerrvilletx

It would be nice to be able to set the "default" split policy for newly created domains. I want the "default" policy to be duplicating the values instead of using the default value of the field. Most of our fields do not have a default field value assigned at the database level because it has caused issues in workflows in the past.

I also agree that the name Default should be changed to something else. Just see the paragraph above and how confusing that is. Even just using "Field Default", "Default Field Value", "Use Default Value", etc. would help in my opinion.

Únete a la Conversación

Inicia sesión para publicar, seguir contenido y más. ¿Nuevo aquí? Regístrate gratis.