Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Conversion en 4D v17 Bienvenue dans le manuel "Conversion en 4D v17" qui vous p

Conversion en 4D v17 Bienvenue dans le manuel "Conversion en 4D v17" qui vous présente les différents points à contrôler avant, pendant et après conversion d'une base 4D v16 en 4D v17. La conversion d'une base 4D v16 doit s'effectuer sans problèmes en 4D v17 à quelques préconisations près, détaillées dans le chapitre Principes de conversion. Une fois la conversion faite, il y a toutefois quelques points à vérifier, comme de Nouvelles options de compatibilité et des Changements de comportement tant au niveau de l'application qu'au niveau des commandes 4D, qu'il faut appréhender pour utiliser au mieux les nouveautés 4D v17. Et enfin, ce manuel récapitule les fonctionnalités obsolètes en 4D v17 que le Développeur doit repérer rapidement pour évaluer les temps de mise en place des nouvelles fonctions. Note : Certaines modifications décrites dans ce manuel ont été introduites durant le programme 4D v16 "R-release". Pour les conversions de bases plus anciennes, voire très anciennes, il est souvent nécessaire de faire des conversions avec des versions intermédiaires. Et pour les différents points à contrôler, reportez-vous aux documents de conversion des précédentes versions : 4D v16 : "Conversion en 4D v16" et "Fonctionnalités obsolètes en 4D v16". 4D v15 : "Conversion en 4D v15" et "Fonctionnalités obsolètes en 4D v15". 4D v14 : "Conversion en 4D v14" et "Fonctionnalités obsolètes en 4D v14". 4D v13 : "Conversion en 4D v13" et "Fonctionnalités obsolètes en 4D v13". 4D v12 : "Fonctionnalités obsolètes en 4D v12" (il n'y a pas eu de document "Conversion" pour cette version). 4D v11 : "Conversion en 4D v11 SQL". Principes de conversion Dialogue Compatibilité Changement de comportement Changement de nom ou de thème Fonctionnalités obsolètes Fonctionnalités désactivées Passage de 32 bits à 64 bits Convertir les documents 4D Write en 4D Write Pro Convertir des documents 4D View en 4D View Pro Annexe : Release Notes 4D v16 Rx Annexe : Méthodes utiles pour la conversion - 1 - Principes de conversion A faire avant de convertir 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, fichiers .RSR et .4DR pour les versions antérieures à 4D v11 - voir les documents "Conversion" des versions précédentes), ainsi que le mot de passe Super-Utilisateur pour pouvoir faire une conversion ; Faites une copie de votre base avant conversion ; Faites une vérification de votre syntaxe, même si vous ne souhaitez pas compiler. Cette vérification peut vous alerter sur des erreurs ; Utilisez le Centre de Sécurité et de Maintenance pour vérifier et réparer structure et données ; Vérifiez si vous avez des PICTS à l'aide de la commande GET PICTURE FORMATS et convertissez-les avec la commande CONVERT PICTURE. Dans 4D à compter de la v14, par défaut les codecs QuickTime ne sont plus pris en charge. Par compatibilité, dans une version 32 bits, vous pouvez les réactiver 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. A noter toutefois que la prise en charge de QuickTime sera définitivement supprimée dans les prochaines versions de 4D. 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. Comment convertir Les bases de données en version 16 de 4D ou 4D Server (ainsi que les bases en v11, v12, v13, v14 et v15) peuvent être converties avec 4D version 17 (fichiers Structure et données). Vous pouvez convertir n'importe quel fichier de Structure interprétée. Pour cela il suffit de lancer 4D v17 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 v17 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 v14 et antérieures. Dans ce cas, un second dialogue apparaît : - 2 - Ce fichier de données est alors converti en version 17 mais pourra toujours être ouvert et utilisé avec 4D v15 ou 4D v16. Les données n'ont pas besoin d'être converties pour des bases en 4D v15 ou 4D v16. 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"), 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 v17 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 rapidement. Pour plus d'informations, référez-vous au chapitre Page Compatibilité. Après conversion Utilisez à nouveau le Centre de Sécurité et de Maintenance (CSM) pour vérifier et 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 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. - 3 - 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 : Reconstruction des index La conversion d'une base v16 en v17 ne nécessite pas la reconstruction des index (hormis pour une version japonaise de 4D). Mais si la mise à jour se fait d'une version plus ancienne (notamment si la mise à jour de la bibliothèque Unicode - ICU - International Components for Unicode - est nécessaire), tous les index des champs de type texte uploads/Litterature/ id-3869.pdf