Principes de conversion

• Vous devez posséder une version "interprétée" de la base (fichier xxxx.4DB pour la structure, fichier xxxx.4DD pour les données, ainsi que le mot de passe Super-Utilisateur pour pouvoir faire une conversion ;

• La version la plus ancienne que vous pouvez convertir avec 4D v18 est la version 4D v11. Pour une version plus ancienne, vous devez passez par une version intermédiaire (version entre 4D v11 et 4D v17, avec vérification/réparaton Structure et Données) puis convertir en 4D v18. Voir les documents "Conversion" des versions précédentes),

• Faites une vérification de votre syntaxe, même si vous ne souhaitez pas compiler. Cette vérification peut vous alerter sur des erreurs ;

• Faites une copie de votre base avant conversion ;

• Utilisez le Centre de Sécurité et de Maintenance pour vérifier et réparer Structure et Données .

• La prise en charge de QuickTime est définitivement supprimée.
  • Pour convertir les images au format obsolète (PICT), vous devez être en version 4D v17 32-bit et vérifier si vous avez des PICTS à l'aide de la commande [#cmd id="1406"] et les convertir avec la commande CONVERT PICTURE.
  • Pour information, ar compatibilité, dans une ancienne version 32 bits, vous pouvez réactiver la prise en charge QuckTime dans votre base à l’aide du sélecteur Prise en charge QuickTime de la commande SET DATABASE PARAMETER . La modification de cette option nécessite le redémarrage de la base. 
  • Pour convertir les images au format obsolète : voir annexe Conversion des picts en structure.

• (optionnel) Possibilité de mettre en place des clefs primaire si vous avez besoin de journaliser des données (à partir de la version 14) (cf. Clé primaire dans le manuel Mode Développement). Il est fortement conseillé de les mettre en place, mais cela peut être fait après la conversion.

• Depuis la version 13.5, vos champs uniques doivent obligatoirement être indexés. Vous ne serez plus autorisé à créer /modifier un enregistrement d'un champ unique non indexé : la tentative d'enregistrer l'enregistrement génèrera une erreur (-9998 enregistrement unique existe, 1088 L'index est invalide ou manquant).
  Pour créer les index manquants ou générer un fichier disque listant les champs non-indexés, reportez-vous à l'annexe Pour créer les index manquants.

Les bases de données en version 17 de 4D ou 4D Server (ainsi que les bases de 4D v11 à 4D v17) peuvent être converties avec 4D version 18 (fichiers Structure et données). Vous pouvez convertir n'importe quel fichier de Structure interprétée. Pour cela il suffit de lancer 4D v18 et d'ouvrir votre fichier de Structure en interprété, le fichier xxx.4DB.

• Conversion du fichier de structure (.4DB)

Un dialogue vous avertit de la conversion du fichier de structure et, en fonction de la version de départ, de la conversion du fichier de données :

Votre fichier de structure est converti en 4D v18 et ne pourra plus être ouvert dans une version antérieure.

• Conversion du fichier de données (.4DD)

Les données doivent être converties pour des bases en version 4D v11 à 4D v14. Dans ce cas, un second dialogue apparaît :

Ce fichier de données est alors converti en version 18 mais pourra toujours être ouvert et utilisé avec 4D v15, 4D v16 ou 4D v17.

Les données n'ont pas besoin d'être converties pour des bases en 4D v15, 4D v16 ou 4D v17.

• Dialogue de mise en place de l'historique

Si les clefs primaires ne sont pas mises en place, 4D vous demandera de le faire en affichant le dialogue ci-dessous :

Il est conseillé de les mettre en place (bouton "Utiliser l'assistant"), mais cette étape peut être faite plus tard (bouton "Continuer"), notamment pour les tables nécessitant une journalisation (pour une sauvegarde). Pour plus d'informations, référez-vous au chapitre Gestionnaire de clés primaires.

• Dialogue de passage temporaire en unicode

Si vous ouvrez votre application en 4D v18 (qui est en 64 bits), et que votre application de départ n'est pas en unicode, 4D vous proposera de passer temporairement votre base en unicode.

L'unicode permettant un gain très net de rapidité, cette étape aurait dû être franchie depuis plusieurs versions. Si ce n'est pas le cas, faites-le car une base non-unicode ne peut pas passer en 4D v18. Pour plus d'informations, référez-vous au chapitre Page Compatibilité.

Utilisez à nouveau le Centre de Sécurité et de Maintenance (CSM) pour vérifier ou réparer structure et données.

Informations sur la structure :

• détection des méthodes orphelines (__Orphan__xxxxx) qui vous sont signalées en avertissements dans le compte-rendu du CSM et peuvent être supprimées sans problème à partir de l'Explorateur (après vérification que le code ne peut plus vous servir) ;

• détection des doublons : les doublons de noms des objets sur les formulaires ne sont plus autorisés : ils vous sont signalés en avertissements dans le compte-rendu du CSM. Il suffit de demander une réparation de la base pour que les noms soient modifiés (attention dans ce cas à la programmation sur les noms d'objets).

• détection des Images obsolètes (format PICT). Vérifier l'application dans le chapitre CSM.
  Voir le paragraphe Images au format PICT dans le manuel Fonctionnalités obsolètes ou supprimées. Ces warnings peuvent concerner les images statiques ainsi que les images stockées dans la bibliothèque d'images ou dans les objets de formulaire.
  
  Note : Pour convertir ces images : voir annexe Conversion des picts en structure.

• Caractères indésirables dans les noms  (".", "[", and "]")
  A compter de 4D v16 R4, l'utilisation de points (.) et/ou de crochets ([ ]) est déconseillée dans les éléments suivants :
  • noms de variables
  • noms de table
  • noms de champs
  • noms de méthodes projet

Pour aider les développeurs à mettre leur application en conformité avec cette règle, l'action Vérifier l'application recherche automatiquement la présence de ces caractères indésirables dans les noms de variables, de tables, de champs et de méthodes. Si ces caractères sont détectés, des "anomalies" sont signalées par le CSM et le fichier de compte rendu contient les avertissements adéquats :



Dans ce cas, il est fortement recommandé de renommer ces éléments dans votre application.

Informations sur les données :

• détection de doublons dans des champs uniques :
  
  Des informations complémentaires sont fournies : Lors de l'utilisation du CSM ou d'une commande telle VERIFY DATA FILE, les fichiers d'historique générés contiennent désormais les noms des tables et des champs en cause, ainsi que chaque valeur dupliquée.
  A noter : Lors de la saisie de données, la boîte de dialogue d'erreur "Clé dupliquée" contient désormais les noms de la table et du champ concernés, ainsi que la valeur dupliquée, et la commande GET LAST ERROR STACK contient également des informations détaillées sur les éventuels doublons.
  Lorsque 4D ouvre un fichier de données, s'il est nécessaire de construire (ou de reconstruire) un index, les doublons sont désormais automatiquement détectés dans le ou les champ(s) associé(s) déclaré(s) unique(s). Dans ce cas, une boîte de dialogue d'alerte spécifique est affichée avant l'ouverture de la base, fournissant à l'utilisateur les informations nécessaires pour identifier et supprimer les doublons :
  
  

Suite à la mise à jour de la librairie Unicode (ICU - International Components for Unicode - en version 63.1 dans 4D v17R5), la conversion d'une base v17 en v18 entraîne la reconstruction des index des champs de type texte (Alpha et Texte) et de mot-clés. Cette opération s'effectue automatiquement à la première ouverture de la base (attention : la durée de l'opération peut être conséquente).

Note : Depuis 4D v16, nous avons optimisé de façon importante l'algorithme de réindexation globale de la base de données. Tout le processus a été revu, et l'opération peut s'effectuer désormais jusqu'à deux fois plus rapidement. Une réindexation globale est nécessaire, par exemple, après une réparation de la base de données ou lorsque le fichier .4dindx a été supprimé.

Il est toujours possible d'ouvrir une base de données en version N Rx avec une version 4D vN.x et vice versa (par exemple, une version v17 Rx peut être rouverte en v17.x). Simplement le code utilisant les nouvelles fonctionnalités ne fonctionnera pas et devra être désactivé.

En revanche, une base convertie en vN ne peut plus être ouverte en 4D vN-1. Par exemple, une base convertie en v18 ne pourra pas être rouverte en v17.