Vérifiez que votre base de données ne contient pas de nouveaux mots réservés dans les identificateurs, les colonnes et les variables. Dans le premier dialecte SQL, ces mots ne peuvent en principe pas être utilisés (vous devrez les renommer). Dans le dialect 3, ils peuvent être utilisés, mais doivent être encadrés par des guillemets doubles.

Vous trouverez une liste des nouveaux mots-clés et des mots réservés dans les notes de version 3.0 et 4.0 au chapitre Mots réservés et changements. Les mots-clés peuvent être utilisés comme identifiants, bien que cela ne soit pas recommandé.

Depuis Firebird 5.0, vous pouvez afficher la liste complète des mots-clés et des mots réservés avec une requête :

Cette requête peut être exécutée sur n’importe quelle base de données avec ODS 13.1, telle que employee.db fournie avec Firebird 5.0.

La colonne RDB$KEYWORD_NAME contient le mot-clé lui-même, et RDB$KEYWORD_RESERVED indique si le mot-clé est réservé.

Concerne : lors de la migration à partir de Firebird 2.5.

Toutes les colonnes de sortie des curseurs PSQL déclarés comme DECLARE CURSOR doivent avoir un nom explicite ou un alias. La même chose s’applique aux curseurs PSQL utilisés en tant que FOR SELECT …​ AS CURSOR <cursor name> DO …​.

Concerne : lors de la migration à partir des versions 2.5 et 3.0 de Firebird.

Firebird 4.0 introduit de nouveaux types de données :

Les deux derniers types ne posent pas beaucoup de problèmes parce que vous ne les avez jamais utilisés auparavant et que les expressions ne les renvoient généralement pas.

Certaines expressions peuvent maintenant retourner les types NUMERIC(38, x), DECIMAL(38, x) et INT128. Nous parlerons de la solution de ce problème plus tard, car ils ne sont généralement pas visibles au stade de la modification de l’ODS.

Les expressions CURRENT_TIMESTAMP et CURRENT_TIME renvoient maintenant les types TIMESTAMP WITH TIME ZONE et TIME WITH TIME ZONE.

Pour les anciennes bibliothèques et applications clientes, vous pouvez installer le type mode de compatibilité, Cependant, cela ne sera pas utile dans les procédures stockées, les fonctions et les déclencheurs. Vous devez utiliser les expressions LOCALTIMESTAMP et LOCALTIME au lieu de CURRENT_TIMESTAMP et CURRENT_TIME lorsque vous ne voulez pas obtenir des types de données avec des fuseaux horaires. Ces expressions ont été spécifiquement introduites dans les versions correctives de Firebird 2.5.9 et Firebird 3.0.4 afin que vous puissiez préparer vos bases de données à l’avance pour la migration vers Firebird 4.0 et plus.

L’affectation d’une variable (colonne) de type TIMESTAMP à la valeur de l’expression CURRENT_TIMESTAMP effectuera une conversion de type, c’est-à-dire un CAST(CURRENT_TIMESTAMP AS TIMESTAMP) implicite, de sorte que même sans remplacer CURRENT_TIMESTAMP et CURRENT_TIME par LOCALTIMESTAMP et LOCALTIME, tout fonctionnera toujours, mais les performances peuvent chuter dans certains cas. Par exemple :

Ici, le champ t est de type TIMESTAMP et CURRENT_TIMESTAMP renvoie TIMESTAMP WITH TIME ZONE, ce qui réduit les performances de INSERT dans une telle table.

Concerne : lors de la migration à partir des versions 2.5 et 3.0 de Firebird.

Firebird 4.0 a redéfini la syntaxe des valeurs littérales de la date et de l’heure.

Les littéraux 'NOW', 'TODAY', 'TOMORROW', 'YESTERDAY' avec les préfixes TIMESTAMP, DATE, TIME sont désormais interdits. La raison en est que la valeur de ces littéraux était calculée lors de la préparation des requêtes DSQL ou de la compilation des modules PSQL, ce qui conduisait à des résultats inattendus.

Si quelque chose comme TIMESTAMP 'NOW' a été utilisé dans des requêtes DSQL dans le code de l’application ou dans le PSQL porté, il y aura un problème de compatibilité avec Firebird 4 et plus.

Vous devez éliminer ces littéraux, par exemple en les remplaçant par une conversion explicite CAST('NOW' AS TIMESTAMP), dans le code de vos procédures et fonctions avant de convertir votre base de données vers le nouvel ODS.

En outre, il convient de vérifier d’autres éléments littéraux de date et d’heure avec l’attribution explicite d’une date (heure) connue. Auparavant, ces littéraux permettaient de délimiter des parties de la date et de l’heure qui n’étaient pas conformes à la norme. Désormais, ces délimiteurs sont interdits. Vous pouvez en savoir plus sur les formats autorisés pour les littéraux de date et d’heure dans le "Firebird 5.0 SQL Language Guide" dans le chapitre "Litérals de Date et Heure".

Concerne : lors de la migration à partir des versions 2.5 et 3.0 de Firebird.

Depuis Firebird 4.0, si une instruction INSERT contient une phrase RETURNING qui fait référence à des colonnes de la table de base, l’appelant doit se voir accorder le privilège SELECT approprié.

Concerne : lors de la migration à partir de Firebird 2.5.

Firebird 3.0 a apporté une amélioration importante appelée "stabilité du curseur". En conséquence de cette amélioration, certaines requêtes peuvent fonctionner différemment. Ceci est particulièrement vrai pour les requêtes qui modifient une table et la lisent dans le même curseur. La stabilité du curseur élimine de nombreux bogues présents dans les versions précédentes de Firebird, dont le plus célèbre est la boucle infinie dans une requête :

Il est peu probable que vos applications contiennent uniquement des demandes de ce type, mais la stabilité du curseur peut ne pas apparaître dans des cas évidents :

Si vous avez de tels cas dans votre code, nous vous recommandons de réécrire ces parties pour prendre en compte l’effet de la "stabilité du curseur".

Après la restauration, vous pouvez voir les avertissements suivants dans le fichier restore.log.

Cela signifie que vous avez des UDF qui sont déclarés dans la base de données, mais que leur bibliothèque est manquante. Ce que vous devez faire dans ce cas a déjà été décrit ci-dessus. Mais il s’agissait principalement de vos bibliothèques d’UDF. Cependant, si vous avez utilisé des UDFs du kit fourni avec Firebird, à savoir ib_udf et fbudf, vous pouvez les remplacer par des fonctions intégrées ou par des analogues UDR sûrs situés dans la bibliothèque udf_compat.dll. Pour ce faire, vous devez exécuter le script SQL de migration fourni avec Firebird 5.0, qui se trouve dans misc/upgrade/v4.0/udf_replace.sql. Cela se fait avec la commande suivante

Si vous migrez depuis Firebird 4.0, il existe un moyen plus rapide de mettre à jour l’ODS que la sauvegarde/restauration.

La méthode traditionnelle pour mettre à jour une ODS (On-Disk Structure) consiste à effectuer une sauvegarde sur l’ancienne version de Firebird et à la restaurer sur la nouvelle. Il s’agit d’un processus assez long, en particulier pour les grandes bases de données.

Cependant, dans le cas d’une mise à niveau d’une version mineure de l’ODS (le numéro après le point), la sauvegarde/restauration est redondante (seuls les tables et champs système manquants et certains paquets doivent être ajoutés). Un exemple d’une telle mise à jour est la mise à jour d’ODS 13.0 (Firebird 4.0) vers ODS 13.1 (Firebird 5.0), puisque la version majeure d’ODS 13 reste la même.

A partir de Firebird 5.0, il est maintenant possible de mettre à jour une version mineure d’ODS sans avoir à effectuer une longue opération de sauvegarde et de restauration. L’utilitaire gfix avec le commutateur -upgrade est utilisé dans ce but.

Points clés :

Vous devez donc suivre les étapes ci-dessous pour mettre à jour rapidement votre ODS :

Cette méthode de mise à jour de l’ODS, contrairement à la sauvegarde/restauration, prend quelques secondes (nous parlons de gfix -upgrade), et non des minutes ou des heures.

Concerne : lors de la migration à partir des versions 2.5 et 3.0 de Firebird.

Depuis Firebird 4.0, une nouvelle méthode d’accès Refetch a été introduite pour optimiser le tri des ensembles de données larges. Un ensemble de données large est un ensemble de données dans lequel la longueur totale des champs d’enregistrement est importante.

Historiquement, lorsqu’il effectue un tri externe, Firebird écrit à la fois les champs clés (c’est-à-dire ceux spécifiés dans la phrase ORDER BY ou GROUP BY) et les champs non-clés (tous les autres champs référencés dans la requête) dans des blocs de tri qui sont soit stockés en mémoire, soit dans des fichiers temporaires. Une fois le tri terminé, ces champs sont relus à partir des blocs de tri.Cette approche est généralement considérée comme plus rapide car les enregistrements sont lus à partir des fichiers temporaires dans l’ordre des enregistrements triés, plutôt que d’être sélectionnés de manière aléatoire à partir de la page de données.Cependant, si les champs non-clés sont grands (par exemple, de longs VARCHARs sont utilisés), cela augmente la taille des blocs de tri et résulte donc en plus d’opérations d’entrées-sorties pour les fichiers temporaires. Firebird 4 offre une approche alternative (méthode d’accès Refetch) où seuls les champs clés et les enregistrements DBKEY sont stockés à l’intérieur des blocs de tri, et les champs non-clés sont récupérés à partir des pages de données après le tri. Cela permet d’améliorer les performances de tri dans le cas de longs champs non clés.

Ainsi, les plans de vos requêtes qui utilisent le tri peuvent changer. Un nouveau paramètre de configuration InlineSortThreshold est introduit pour contrôler cette méthode d’accès. La valeur spécifiée pour InlineSortThreshold définit la taille maximale d’un enregistrement de tri (en octets) qui peut être stocké en ligne, c’est-à-dire à l’intérieur d’un bloc de tri. Zéro signifie que les enregistrements sont toujours rechargés. La valeur optimale de ce paramètre doit être choisie de manière expérimentale. La valeur par défaut est de 1000 octets.

Prenons l’exemple suivant :

Avant Firebird 4.0, les 4 champs étaient toujours inclus dans les blocs de tri. Depuis Firebird 4.0, si la longueur totale des champs field_1 . field_4 dépasse la valeur de InlineSortThreshold, seul field_1 sera inclus dans les blocs de tri et ensuite Refetch sera exécuté.

L’optimisation des JOIN OUTER dans Firebird pose un certain nombre de problèmes.

Tout d’abord, le OUTER JOIN ne peut actuellement être exécuté que par un seul algorithme de connexion NESTED LOOP JOIN, ce qui pourrait être modifié dans les versions futures.

Deuxièmement, lorsque les threads sont reliés par des connexions externes, l’ordre de connexion est strictement fixe, c’est-à-dire que l’optimiseur ne peut pas le modifier pour que le résultat reste correct.

Cependant, s’il y a un prédicat pour le champ WHERE de la table "de droite" (jointe) dans la condition WHERE qui ne gère pas explicitement la valeur NULL, il n’y a pas d’intérêt à faire une jointure externe. Dans ce cas, à partir de Firebird 5.0, une telle jointure sera convertie en jointure interne, permettant à l’optimiseur d’appliquer la gamme complète des algorithmes de jointure disponibles.

Supposons que vous ayez la requête suivante :

Firebird 5.0 convertira implicitement une telle requête en une forme équivalente :

Si LEFT JOIN a été utilisé comme un indice pour spécifier l’ordre de jointure de manière très active, il peut être problématique de réécrire de nombreuses requêtes d’une nouvelle manière. Pour ces développeurs, il existe un paramètre de configuration OuterJoinConversion dans firebird.conf ou database.conf. Mettre le paramètre OuterJoinConversion à false désactive la transformation des jointures externes en jointures internes. Notez que ce paramètre est une solution temporaire pour faciliter la migration et peut être supprimé dans les versions futures de Firebird.