Implicaciones de realizar cambios en el Diseño de un Formulario

Este artículo explica las implicaciones de realizar cambios en el diseño de un formulario en ActivityInfo. Está dirigido a los Propietarios de Bases de datos, especialmente a aquellos que gestionan bases de datos que ya han sido desplegadas y están en uso activo.

Objetivo

Después de leer este artículo, usted podrá:

• Entender qué cambios puede y no puede hacer en el diseño de un formulario.
• Anticipar el impacto de esos cambios en los datos existentes, los informes y las reglas de validación.
• Solucionar problemas que puedan surgir después de modificar los campos del formulario.

Lo que puede hacer

1. Actualizar las Etiquetas de los Campos

• Impacto: Ningún efecto en los datos introducidos previamente.
• Consideraciones: Actualizar una etiqueta puede cambiar la forma en que los usuarios interpretan el campo durante la entrada de datos. Asegúrese de comunicar cualquier cambio de etiqueta a los equipos de entrada de datos para evitar confusiones.

2. Actualizar las Descripciones de los Campos

• Impacto: Ningún efecto en los datos existentes.
• Consideraciones: Utilice descripciones claras para guiar a los usuarios. Actualizar las descripciones es útil para aclarar las instrucciones sin afectar a los registros enviados previamente.

3. Actualizar los Códigos de los Campos

• Impacto: Las fórmulas y referencias que utilizan este campo se actualizan automáticamente con el nuevo código, con la excepción de las tablas calculadas y las medidas calculadas en los informes.
• Consideraciones: Aunque ActivityInfo actualiza las referencias internas automáticamente, verifique dos veces los campos calculados y los informes para confirmar que siguen comportándose como se espera.

4. Actualizar las Reglas de validación de los Campos

• Impacto: Actualizar las reglas de validación puede hacer que los registros añadidos previamente se vuelvan inválidos si ya no cumplen los nuevos criterios de validación. Los registros existentes no se verán afectados, pero no será posible editar un registro hasta que se corrija el problema de validación.
• Próximos pasos: Revise los mensajes de validación y corrija los registros inválidos para restaurar la validez de los datos.

5. Actualizar las Reglas de relevancia de los Campos

• Impacto: Al igual que con las reglas de validación, los cambios en las reglas de relevancia pueden hacer que los registros más antiguos se vuelvan inválidos o que los campos se muestren/oculten de forma inconsistente. Los registros existentes no se verán afectados, pero si edita un registro, no podrá guardar los cambios hasta que se corrija el problema de validación.
• Próximos pasos: Revise los registros afectados y realice los ajustes manuales necesarios.

6. Actualizar la etiqueta o el orden de las opciones en los Campos de Selección Única/Múltiple

• Impacto: Los valores de las opciones actualizadas se aplicarán automáticamente a todos los registros existentes.

• Consideraciones:

• No reordene las opciones existentes cambiando sus etiquetas.

• Si cambia el nombre de una opción, esta cambiará en todos los registros existentes en los que se haya seleccionado previamente esa opción.

• Eliminar una opción significa que ese valor desaparecerá de todos los registros que la utilizaban.

7. Eliminar una opción de un campo de Selección Única o Múltiple

• Impacto: Cualquier registro anterior en el que se haya seleccionado esa opción mostrará un espacio en blanco para ese campo (porque el ID de la opción almacenada ya no coincide con ninguna opción definida). Si el campo está marcado como obligatorio, el registro se marcará como inválido.
• Consideraciones: Antes de eliminar opciones, considere la posibilidad de limpiar los registros que utilizaban la opción.

8. Añadir Nuevos Campos

• Impacto: Los registros existentes se conservan, pero los nuevos campos estarán vacíos para esos registros.
• Consideraciones: Si el nuevo campo está marcado como Obligatorio, los registros más antiguos se volverán inválidos hasta que se rellene ese campo. Si edita un registro existente al que le falta este campo, no podrá guardar los cambios hasta que proporcione un valor para el campo.
• Recomendación: Considere la posibilidad de dejar los nuevos campos como opcionales si los añade a mitad del proyecto, o planifique un paso de limpieza de datos.

9. Eliminar Campos Existentes

• Impacto:

• Eliminar un campo elimina todos los datos introducidos previamente en ese campo.

• Cualquier campo calculado, regla de relevancia o regla de validación que haga referencia al campo eliminado se romperá y deberá ser actualizado.

• Los informes pueden romperse por el campo eliminado.

• Recuperación: Puede recuperar un campo eliminado (y sus datos) a través del Registro de auditoría.

• Recomendación: Si desea dejar de recolectar nuevos datos pero conservar los valores históricos, puede mantener el campo y marcarlo como "Escondido de la Entrada/Tabla".

Lo que no puede hacer

1. Actualizar el Tipo de Campo

• No puede cambiar el tipo de un campo existente (por ejemplo, de "Texto" a "Fecha").

• Enfoque recomendado:

• Añada un nuevo campo con el tipo de campo deseado.

• Migre los datos históricos del campo antiguo al nuevo exportando e importando registros.

• Actualice cualquier campo calculado, regla de relevancia o regla de validación que haga referencia al campo antiguo para que apunten al nuevo.

Consideraciones relacionadas

1. Campos Calculados: Cualquier cambio en los códigos de los campos, las dependencias o los formularios vinculados puede afectar a las fórmulas. Verifique siempre que los campos calculados siguen siendo correctos después de editar el diseño del formulario. Aunque ActivityInfo actualiza automáticamente las referencias de los campos en la mayoría de las fórmulas cuando se cambian los códigos de los campos, las tablas calculadas no se actualizan automáticamente y pueden romperse si cambia el código del campo. Asegúrese de revisar las tablas calculadas manualmente después de un cambio en el código de un campo.
2. Formularios relacionados (Principal/Subformulario): Evite cambiar el nombre o eliminar los campos utilizados como claves de enlace. Hacerlo puede romper las relaciones entre los registros del formulario principal y del subformulario.
3. Informes y Paneles: La eliminación de un campo o el cambio del código del campo puede afectar a las fórmulas utilizadas en los informes, gráficos o paneles que utilizan ese campo. Revise y actualice cualquier informe dependiente después de los cambios de diseño.
4. Recolección de datos sin conexión: Si los usuarios están recolectando datos en el campo mientras trabajan sin conexión, los cambios en el diseño del formulario no se aplican hasta la siguiente sincronización. Esto puede afectar a los registros pendientes y a los registros borradores.

Registros pendientes:

• Los Registros pendientes se envían al servidor tal cual, incluso si el formulario ha sido actualizado desde entonces.
• Aparecerán como inválidos en la vista de tabla interactiva o cuando se abran para su edición si ya no cumplen con las reglas de validación o relevancia actualizadas.
• La única situación que bloqueará el envío de registros pendientes es un cambio en los permisos del usuario. Si un usuario ya no tiene permiso para enviar un registro, la sincronización fallará.

Registros borradores:

• Los registros borradores se almacenan localmente en el dispositivo y se vuelven a validar cuando el usuario sincroniza y descarga la última versión del formulario.

• Los borradores que ya no cumplen con las reglas de validación o relevancia actualizadas no pueden ser enviados hasta que sean corregidos.

• Los usuarios deben revisar cualquier borrador inválido y actualizarlo para que coincida con la última versión del formulario.

Lecturas adicionales sobre la integridad referencial y la validez de los registros.

Solución de problemas comunes