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, así como también la contraseña Diseñador para realizar una conversión;

• La versión más antigua que puede convertir directamente con 4D v18 es una aplicación 4D v11. Si su aplicación es anterior, debe utilizar una versión intermedia (entre v11 y v17, con verificación/reparación datos y estructura), luego convertir a v18. Consulte los documentos de "Conversión" para versiones anteriores.

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

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

• QuickTime ya no se soporta. 

• Para convertir imágenes en formato obsoleto (PICT), debe estar en v17 32 bits y verificar si tiene PICTs con el comando GET PICTURE FORMATS y convertirlas con el comando CONVERT PICTURE.
  A partir de 4D v14, los códecs QuickTime por defecto ya no son soportados.
  
  
• Para información sobre 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 17 de 4D o 4D Server (así como también las bases de 4D v11 a 4D v17) son convertidas 4D v18 (archivos Estructura y datos). Puede convertir cualquier archivo de estructura interpretado. Para ello, solo lance 4D v18 y abra su archivo de Estructura en modo interpretado (archivo xxx.4DB).

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

Un diálogo le informa sobre la conversión del archivo de estructura y, dependiendo de la versión de inicio, de la conversión del archivo de datos:

Su archivo de estructura se convierte a 4D v18 y no se puede abrir en una versión anterior.

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

Los datos se deben convertir para las bases en versión 4D v11 a 4D v14. En este caso, aparece un segundo diálogo:

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

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

• 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 v18 (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:
  
  

Como consecuencia de la actualización de la librería Unicode (ICU versión 63.1 en 4D v17 R5), la conversión de una base v17 a v18 requiere la reconstrucción de los índices de los campos de tipo texto y de palabras claves. Esto se hace automáticamente cuando se abre la base de datos por primera vez (advertencia: esta operación puede llevar una cantidad de tiempo considerable).

Nota: a partir de 4D v16, hemos mejorado significativamente el algoritmo de reindexación global de la base de datos. Todos los procesos están siendo revisados y esta operación ahora puede ser hasta dos veces más rápida. Se requiere reindexar globalmente, 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 versión X.Rx con una versión 4D vX.x y viceversa (por ejemplo, una base en versión 17 Rx puede ser abierta  por una v17.x). Sin embargo, el código que usa las nuevas funcionalidades no funcionará y debería estar deshabilitado.

Sin embargo, una base de datos convertida a vX ya no se puede abrir en 4D vX-1.  Por ejemplo,una base convertida a v18 no puede reabrirse con una versión 4D v17.x.