Documentation/HowTo/MigrateFromHSQLDB/fr

La version LibreOffice 6.1 va progressivement remplacer la base de données interne HSQLDB par la base de données interne Firebird. En premier lieu, ceci est indiqué par le fait que les bases de données Firebird existantes ne nécessitent plus l’activation du mode expérimental.

Si le mode expérimental est activé dans LibreOffice, la boîte de dialogue suivante s'affiche lors de l'accès à des tables d'une base de données interne HSQLDB :



L'option Plus tard doit être choisie jusqu'à ce que les précautions suivantes aient été prises.


 * 1) Sauvegarder les fichiers de base de données HSQLDB
 * 2) Copier les vues à partir du code SQL et les enregistrer en tant que requêtes. Ajuster ensuite et enregistrer à nouveau comme vues. Les vues ne peuvent pas être éditées dans Firebird pour le moment!
 * 3) Les noms des tables et des colonnes dans Firebird ne peuvent avoir plus de 31 caractère. Ajuster si nécessaire.
 * 4) En raison d'un bug, dans tous les champs de date, les champs d’heure et les champs de date / heure des tables doivent être complétés par un champ qui stocke le contenu sous forme de texte.
 * 5) En raison d'un bug, les images lues dans HSQLDB ne sont pas affichées dans la base de données Firebird après la migration.
 * 6) Les tableaux de texte purs (table intégrée *.csv, etc.) ne sont pas possibles sous Firebird.

Migrer les champs de date, les champs d'heure et les champs de date / heure
L'assistant de migration ne gère pas correctement la migration des champs de date, des champs d'heure et des champs de date / heure. Ceci en raison du fait que HSQLDB travaille avec des fuseaux horaires locaux. Au cours de la migration date-heure, les valeurs sont modifiées en heures d'été qui sont 2 heures plus tôt, mais ne sont que d'une heure en hiver. Les dates sont toujours avancées d'un jour, et ainsi de suite. La méthode suivante permet d'extraire correctement les valeurs appropriées de HSQLDB dans la base de données Firebird, puis de créer à nouveau des valeurs d'heure et de date :

1. Tables contenant des champs de date, des champs d'heure et des champs de date / heure dans la base de données HSQLDB leur ajouter chacune un champ VARCHAR: "Date_T" VARCHAR (10), "Time_T" VARCHAR (8), "DateTime_T" VARCHAR (19) 2. Exécuter la commande suivante via Outils → SQL : UPDATE "Table" SET "Date_T" = CAST ("Date" AS VARCHAR (10)); UPDATE "Table" SET "Time_T" = CAST ("Time" AS VARCHAR (8)); UPDATE "Table" SET "DateTime_T" = LEFT (CAST ("DateTime" AS VARCHAR (30)), 19); 3. Une fois que tous les champs sont disponibles également en tant que champs de texte dans les tables, la migration peut s'effectuer. Par la suite, le fichier de base de données Firebird migré doit être à nouveau mis à jour: UPDATE "Table" SET "Date" = "Date_T"; UPDATE "Table" SET "Time" = "Time_T"; UPDATE "Table" SET "DateTime" = "DateTime_T";

Après cette action, les valeurs correspondantes de la base de données HSQLDB sont également disponibles dans le nouveau fichier de base de données Firebird. Les champs "Date_T", "Time_T" et "DateTime_T" peuvent être ensuite supprimés.

Rendre les images des tables dans les formulaires visibles et modifiables
L'assistant de migration crée des champs de type image [BLOB] dans les champs responsables des images de la base de données HSQLDB (image[Longvarbinary]). Ce type est présent dans l'interface graphique, mais probablement pas lié au type de données correct. Afin de rendre ces images à nouveau visibles, elles doivent être copiées dans un champ de type BLOB [BLOB], de sorte qu'un affichage et une modification du contenu de l'image dans le formulaire soient possibles. Les rapports ne sont actuellement pas en mesure d'afficher des images à partir de fichiers de base de données Firebird.



Même si aucune modification n'a été faite par l'utilisateur sur un champ d'image, le message qu'une modification n'est pas possible s'affiche et à la place la colonne peut être supprimée et recréée. Il est préférable de sélectionner Non, sinon les données stockées dans le champ seront perdues.

Les tables contenant des images doivent être complétés par un champ BLOB : "Image_N" BLOB [BLOB]

2. Lors de l'enregistrement, le type de données du champ d'image créé lors de l'import ne doit pas être modifié.

3. Exécuter la commande suivante via Outils → SQL : UPDATE "Table" SET "Image_N" = "Image"; 4. Ouvrir l'éditeur de table, supprimer l'ancienne colonne "image" et ne pas autoriser le type de données du nouveau champ image à être modifié en supprimant le champ.

5. Ouvrir l'éditeur de table, ajouter une nouvelle colonne "Image" et ne pas autoriser le type de données d'un champ d'image à être modifié en supprimant le champ.

6. Exécuter la commande suivante via Outils → SQL : UPDATE "Table" SET "Image" = "Image_N"; 7. Ouvrir l'éditeur de table, supprimer la colonne "Image_N" et ne pas autoriser le type de données du nouveau champ d'image à être modifié en supprimant le champ.

Bug de migration pour les sous formulaires et paramètres de requêtes
En raison d'un bug dans le paramètre de migration, les requêtes et les sous-formulaires ne fonctionnent pas correctement. Malheureusement, à cause de cela, le fichier de base de données doit être décompressé et le fichier content.xml contenu doit être traité. Ce fichier indique de manière incorrecte db: parameter-name-substitution = "false"

Cela doit être modifié en    db: parameter-name-substitution = "true" ou il peut être complètement supprimé immédiatement. Ensuite, le content.xml peut être lu dans le fichier de base de données.

Contenu du fichier *.odb après la migration
Le contenu de HSQLDB n'est pas supprimé du fichier *.odb pendant la migration :



Après la migration, le fichier "firebird.fbk" est situé dans le fichier de base de données dans le sous répertoire "basededonnées" en plus de HSQLDB. Ce fichier contient les données migrées et est décompressé dans un répertoire temporaire du système d'exploitation lorsque le fichier de base de données est démarré.

De même, les paramètres précédents du content.xml sont conservés. Le fichier correspondant a juste été renommé "content_before_migration.xml". Pour pouvoir accéder à nouveau aux données de la base de données HSQLDB, il suffit de renommer le nouveau "content.xml" en "content_new.xml" et le fichier "content_before_migration.xml" en "content.xml".

Une fois la migration réussie, le fichier "content_before_migration.xml" et les fichiers "backup", "data", "properties" et "script" situés dans le répertoire "basededonnées" peuvent être supprimés. Ceci est bien sûr recommandé si la base de données était déjà assez étendue auparavant. Enfin, les données ont été doublées lors de la migration.

Personnaliser les fonctions dans les requêtes
De nombreuses fonctions dans les requêtes portent les mêmes noms dans HSQLDB et Firebird et fonctionnent de la même manière. Toutefois, lors de l'ouverture d'une requête qui fonctionnait auparavant dans HSQLDB, il peut arriver qu'un message tel que celui-ci s'affiche :



La fonction IFNULL est inconnue dans Firebird. Un examen de la liste suivante montre que la fonction COALESCE peut être utilisée à la fois dans Firebird et dans la base de données HSQLDB interne. Cette fonction est encore plus universelle car elle peut interroger un nombre illimité de valeurs et le premier hit qui n'est pas NULL renvoie la valeur correspondante. Malheureusement, l'éditeur SQL de base ne permet pas de partager un terme avec Rechercher et remplacer. Sinon, IFNULL pourrait simplement être remplacé par COALESCE si le terme apparaît plus fréquemment dans une requête. Pour de telles transformations, il est donc conseillé de copier la requête dans un simple éditeur de texte avec une fonction de rechercher et remplacer, puis de faire le remplacement et d’écraser l’ancien contenu.

Cela devint plus compliqué lorsque le message suivant apparaît :



Le message d'erreur n'a pas de sens pour l'instant. Aucun détails utiles. Il est apparu ici pour la première fois lorsque la fonction SUBSTRING est apparue dans une requête. Cette fonctionnalité est également connue dans Firebird, mais Firebird ne permet pas la notation abrégée séparée par des virgules, qui elle est possible avec HSQLDB. Au lieu de cela, vous devez réécrire dans SUBSTRING (s FROM start [FOR len]).

Le tableau suivant donne un aperçu des fonctionnalités qui pourraient nécessiter d'être ajustées car elles ne portent pas le même nom dans Firebird ou, dans le pire des cas, n'existent pas du tout. La liste ne dit rien sur le fait que Firebird a moins de fonctions que la base de données HSQLDB interne. Seulement, qu'il n'y a pas de substitut pour certaines fonctions.

Une fonction qui apparaît dans les colonnes HSQLDB et Firebird peut déjà être modifiée avant la migration. Par exemple la combinaison de plusieurs chaînes : CONCAT ainsi que la combinaison avec '+' peuvent déjà être remplacés par '||'. Cette connexion fonctionne dans les deux bases de données internes. Le fonctionnement ultérieur de HSQLDB n’est pas affecté par ce changement.

Une fonction qui apparaît uniquement sous HSQLDB ou Firebird, mais pas dans la colonne du milieu, ne peut pas encore être remplacée. Pour cela, la base de données devrait être migrée en premier. Le code des vues comportant l’une de ces fonctions doit être stocké ailleurs - par exemple comme une requête. La modification du code n’est possible qu’après la migration.

Certaines fonctionnalités ne peuvent pas être migrées. Ceci est indiqué par la note barrée en rouge.

Fonctions du moteur de données dans HSQLDB et Firebird
La première colonne présente les fonctions de HSQLDB, qui ne sont pas disponibles dans Firebird. La deuxième colonne présente les fonctions qui fonctionneront dans HSQLDB et Firebird avec le même résultat. La troisième colonne affiche les fonctions de Firebird, qui doivent être choisies à la place des fonctions de HSQLDB. Ces fonctions donnent le même résultat que les fonctions de la même ligne pour HSQLDB, mais ne sont pas disponibles avec ce nom de fonction dans HSQLDB.

Pour plus d'informations sur les types de champs dans HSQLDB et Firebird, voir Documentation / FirebirdMigration.