Principios para la conversión

• Debe tener una versión "interpretada" de la base (archivo xxxx.4DB para la estructura, archivo xxxx.4DD para los datos, archivos .RSR y .4DR para las versiones anteriores a 4D v11, ver los documentos "Conversión" de las versiones anteriores), así como también la contraseña Diseñador para realizar una conversión;

• Haga una copia de su base antes de la conversión;

• Realice una verificación de sintaxis. Incluso si no desea compilar su base, esta verificación puede ayudarle a alertarle sobre posibles errores;

• Utilice el Centro de Mantenimiento y Seguridad para verificar y reparar la estructura y los datos;

• Compruebe si tiene algún PICT utilizando el comando GET PICTURE FORMATS y conviértalos utilizando el comando CONVERT PICTURE. En 4D a partir de la v14, por defecto los codecs QuickTime no son soportados. Por compatibilidad, en una versión 32 bits, puede reactivarlos en su base con la ayuda de un selector QuickTime Support para el comando SET DATABASE PARAMETER); La modificación de esta opción necesita del reinicio de la base. Sin embargo, tenga en cuenta que el soporte con QuickTime se eliminará permanentemente en futuras versiones de 4D.
  Para convertir imágenes de formato obsoleto: ver Conversión de imágenes en estructura.

• (Opcional) Posibilidad de implementar llaves primarias si se necesita el registro de datos (a partir de la versión 14) (ver Definir o eliminar una llave primaria en el manual Diseño). Se recomienda configurarlos, pero esto se puede hacer después de la conversión.

• Desde la versión 13.5, es obligatorio que los campos Únicos sean indexados. Ya no se permitirá crear/modificar registros para un campo único no indexado: al intentar guardar el registro se generará un error (-9998 registro único existe, el índice 1088 no es válido o falta).
  Para crear índices faltantes o generar un archivo disco que liste los campos no indexados, consulte Para crear los indices faltantes.

Las bases de datos creadas con la versión 16 de 4D o 4D Server (así como también las creadas en v11, v12, v13, v14 y v15) son compatibles con 4D versión 17 (archivos Estructura y datos). Puede convertir cualquier archivo de estructura interpretado. Para ello, solo lance 4D v17 y abra su archivo de Estructura en modo interpretado (archivo xxx.4DB).

• Conversión del archivo de estructura (.4DB)

• Conversión del archivo de datos (.4DD)

Los datos se deben convertir para 4D v14 y bases de datos anteriores. En este caso, aparece un segundo diálogo:

Este archivo de datos se convierte a la versión 17, pero aún se puede abrir y usar con 4D v15 o 4D v16.

No es necesario convertir los datos para las bases 4D v15 o 4D v16.

• Diálogo de configuración del archivo de historial

Si las llaves primarias no están en su lugar, 4D le pedirá que lo haga mostrando el siguiente diálogo:

Es aconsejable configurar las llaves primarias (botón "Usar el asistente"), pero este paso se puede hacer más adelante (botón "Continuar"), para las tablas que requieren el registro (para una copia de seguridad). Para más información, consulte el capítulo  Gestión de llaves primarias.

• Diálogo Unicode temporal

Si abre su aplicación en 4D v17 64 bits y su aplicación de inicio no está en modo Unicode, 4D le ofrecerá cambiar temporalmente su base a Unicode.

Como Unicode mejora la velocidad, este paso debería haberse realizado desde varias versiones. Si este no es el caso, hágalo rápidamente. Para más información, consulte el capítulo Página Compatibilidad.

Utilice el Centro de mantenimiento y seguridad (CSM) para verificar y reparar la estructura y los datos.

Como recordatorio, en la estructura:

• detección de métodos huérfanos (__Orphan__xxxxx) se indican por advertencias en el archivo de historial del CSM y pueden eliminarse utilizando el Explorador (después de comprobar que su código ya no es útil);
• no se permite detección de nombres de objetos duplicados en formularios: se señalan como advertencias en el archivo de historial del CSM. Puede realizar una operación de reparación en la base para modificar estos nombres (en este caso, asegúrese de revisar la programación de los nombres de objetos).

• Detección de imágenes obsoletas (formato PICT). Ver Verificar la aplicación en el capítulo CSM.
  Ver el párrafo Imágenes en formato PICT en el manual de funcionalidades Obsoletas o eliminadas. Estas advertencias pueden afectar tanto a las imágenes estáticas como a las almacenadas en la librería de imágenes o en objetos de formulario.
  
  Nota: para convertir estas imágenes: ver Conversión de imágenes en estructura.
• Caracteres indeseables en los nombres (".", "[", and "]")
  A partir de 4D v16 R4, el uso de puntos (.) Y / o corchetes ([ ]) no se recomienda en los siguientes elementos:
  
  • nombres de variable
  • nombres de tabla
  • nombres de campo
  • nombre de método proyecto
  
  Para ayudar a los desarrolladores a poner sus aplicaciones conforme con esta regla, la acción Verificar la aplicación busca automáticamente la presencia de estos caracteres no deseados en los nombres de variables, tablas, campos y métodos. Si se detectan estos caracteres, el CSM informa sobre "anomalías" y el archivo de historial contiene las advertencias apropiadas:
  
  
  
  En este caso, se recomienda cambiar el nombre de estos elementos en su aplicación.

•  detección de duplicados en campos únicos:
  
  Se ofrece información adicional: When using the MSC or a command like [#cmd id="939"/], the generated log files now contain the names of the tables and fields involved, as well as each duplicate value.
  Cuando se utiliza el CSM o un comando como VERIFY DATA FILE, los archivos de historial generados ahora incluyen los nombres de las tablas y campos en cuestión, así como también cada valor duplicado.
  Nota: al ingresar datos, el cuadro de diálogo de error "Llave duplicada" ahora incluye los nombres de las tablas y campos correspondientes, así como también el valor duplicado y el comando GET LAST ERROR STACK también incluye información detallada sobre cualquier duplicado encontrado.
  Cuando 4D abre un archivo de datos, si es necesario construir (o reconstruir) un índice, los duplicados se detectan automáticamente en cualquier campo asociado que se declare único. En este caso, se muestra un cuadro de diálogo de alerta específico antes de abrir la base de datos, ofreciendo al usuario la información necesaria para identificar y eliminar los duplicados:
  
  

La conversión de una base 4Dv16 en v17 no necesita de la reconstrucción de los índices (con la excepción de una versión japonesa de 4D).

Pero si la actualización se hace de una versión más antigua (especialmente si actualiza de la librería Unicode (ICU - International Components for Unicode), todos los índices de los campos de tipo texto y de palabras claves de 4D fueron reconstruidos. Esta operación se realiza de forma automática cuando se abre la base por primera vez (advertencia: esta operación puede tomar una cantidad significativa de tiempo).

Nota: desde 4D v16, hemos optimizado significativamente el algoritmo de reindexación global de la base de datos. Todos sus procesos fueron revisados y esta operación ahora puede ser hasta dos veces más rápida. La reindexación global es necesaria, por ejemplo, después de reparar la base de datos o cuando se ha eliminado el archivo .4dindx.

Es posible abrir una base de datos en la versión 16.Rx con una versión 4D v16.x y viceversa. Sin embargo, el código que usa las nuevas funcionalidades no funcionará y debería estar deshabilitado. Pero una base de datos convertida a v17 ya no se puede abrir en 4D v16.

Nota: similarmente, una base v17 Rx también puede reabrirse con una versión 4D v17.x.