Gestion des opérateurs de contrôleTraitement des erreurs, codes et messages

Pseudo-colonne `RDB$RECORD_VERSION`

Chaque table contient une pseudo-colonne RDB$RECORD_VERSION de type BIGINT.La pseudo-colonne nommée RDB$RECORD_VERSION renvoie le numéro de la transaction qui a créé la version actuelle de l’enregistrement.

Champ RDB$VALID_BLR

Les tables système RDB$PROCEDURES, RDB$FUNCTIONS et RDB$TRIGGERS contiennent un champ RDB$VALID_BLR. Il est destiné à signaler qu’un module PSQL (procédure ou trigger) peut être invalide après que les domaines ou les colonnes de table dont il dépend aient été modifiés. Dans ce cas, le champ RDB$VALID_BLR est mis à 0 pour les procédures ou les triggers dont le code peut être invalide.

docnext count = 2

Comment cela fonctionne

Dans les déclencheurs, les procédures et les fonctions, les dépendances portent sur les colonnes de la table à laquelle ils font référence, ainsi que sur tout paramètre ou variable défini dans le module à l’aide de la clause TYPE OF.

Après que le noyau Firebird ait modifié un domaine, y compris les domaines implicites créés en interne lors de la définition des colonnes ou des paramètres, Firebird recompile en interne toutes les dépendances.

Note	L’invalidation se produit pour les procédures, les fonctions, les packages et les triggers, mais pas pour les blocs d’instructions DML, qui sont exécutés avec EXECUTE BLOCK.

Tout module qui n’a pas pu être recompilé en raison d’une incompatibilité résultant d’un changement de domaine est marqué comme invalide (le champ RDB$VALID_BLR est mis à 0 dans l’entrée de la table système correspondante (RDB$PROCEDURES ou RDB$TRIGGERS).

La réinitialisation (mise à 1 de RDB$VALID_BLR) se produit lorsque

le domaine est à nouveau modifié et sa nouvelle définition est compatible avec la définition du module précédemment invalide ; ou
le module précédemment invalide est modifié de manière à correspondre à la nouvelle définition du domaine.

La requête ci-dessous recherche les procédures et les triggers dépendant d’un domaine particulier (dans l’exemple, il s’agit du domaine 'MYDOMAIN') et affiche l’état du champ RDB$VALID_BLR :

WITH VALID_PSQL (
    PSQL_TYPE,
    ROUTE_NAME,
    VALID)
AS (SELECT
        'Procedure',
        RDB$PROCEDURE_NAME,
        RDB$VALID_BLR
    FROM
        RDB$PROCEDURES
    WHERE
          RDB$PROCEDURES.RDB$PACKAGE_NAME IS NULL
    UNION ALL
    SELECT
        'Function',
        RDB$FUNCTION_NAME,
        RDB$VALID_BLR
    FROM
        RDB$FUNCTIONS
    WHERE
          RDB$FUNCTIONS.RDB$PACKAGE_NAME IS NULL
    UNION ALL
    SELECT
        'Package',
        RDB$PACKAGE_NAME,
        RDB$VALID_BODY_FLAG
    FROM
        RDB$PACKAGES
    UNION ALL
    SELECT
        'Trigger',
        RDB$TRIGGER_NAME,
        RDB$VALID_BLR
    FROM
        RDB$TRIGGERS
    WHERE
          RDB$TRIGGERS.RDB$SYSTEM_FLAG = 0)
SELECT
    PSQL_TYPE,
    ROUTE_NAME,
    VALID
FROM
    VALID_PSQL
WHERE
      EXISTS(SELECT
                 *
             FROM
                 RDB$DEPENDENCIES
             WHERE
                   RDB$DEPENDENT_NAME = VALID_PSQL.ROUTE_NAME
               AND RDB$DEPENDED_ON_NAME = 'MYDOMAIN');

/*
  Remplacez MYDOMAIN par le nom réel du domaine à tester. Utilisez des lettres majuscules si le domaine a été créé sans tenir compte de la casse - sinon, utilisez l'orthographe exacte du nom de domaine en tenant compte de la casse.
*/

La requête suivante recherche les procédures et les déclencheurs qui dépendent d’une certaine colonne de table (dans l’exemple, il s’agit de la colonne 'MYCOLUMN' de la table 'MYTABLE') et fournit des informations sur l’état du champ RDB$VALID_BLR :

WITH VALID_PSQL (
    PSQL_TYPE,
    ROUTE_NAME,
    VALID)
AS (SELECT
        'Procedure',
        RDB$PROCEDURE_NAME,
        RDB$VALID_BLR
    FROM
        RDB$PROCEDURES
    WHERE
          RDB$PROCEDURES.RDB$PACKAGE_NAME IS NULL
    UNION ALL
    SELECT
        'Function',
        RDB$FUNCTION_NAME,
        RDB$VALID_BLR
    FROM
        RDB$FUNCTIONS
    WHERE
          RDB$FUNCTIONS.RDB$PACKAGE_NAME IS NULL
    UNION ALL
    SELECT
        'Package',
        RDB$PACKAGE_NAME,
        RDB$VALID_BODY_FLAG
    FROM
        RDB$PACKAGES
    UNION ALL
    SELECT
        'Trigger',
        RDB$TRIGGER_NAME,
        RDB$VALID_BLR
    FROM
        RDB$TRIGGERS
    WHERE
          RDB$TRIGGERS.RDB$SYSTEM_FLAG = 0)
SELECT
    PSQL_TYPE,
    ROUTE_NAME,
    VALID
FROM
    VALID_PSQL
WHERE
      EXISTS(SELECT
                 *
             FROM
                 RDB$DEPENDENCIES D
             WHERE
                   D.RDB$DEPENDENT_NAME = VALID_PSQL.ROUTE_NAME
               AND D.RDB$DEPENDED_ON_NAME = 'MYTABLE'
               AND D.RDB$FIELD_NAME = 'MYCOLUMN');

/*
  Remplacez MYTABLE et MYCOLUMN par les noms réels de la table et de sa colonne à vérifier.
  Utilisez des lettres majuscules si la table et sa colonne ont été créées sans tenir compte de la casse - sinon, utilisez l'orthographe exacte du nom de la table et de sa colonne en tenant compte de la casse.
*/

Important

Tous les modules invalides causés par les changements de domaine/colonne sont reflétés dans le champ RDB$VALID_BLR.En revanche, d’autres types de modifications, telles que des modifications du nombre de paramètres d’entrée ou de sortie des procédures, etc., n’affectent pas le champ de validation, même si elles peuvent potentiellement invalider le module.Les scénarios typiques pourraient être les suivants :

Une procédure (B) est définie de telle sorte qu’elle appelle une autre procédure (A) et en lit les paramètres de sortie. Dans ce cas, la dépendance sera enregistrée dans RDB$DEPENDENCIES. La procédure appelée (A) peut ensuite être modifiée pour changer ou supprimer un ou plusieurs paramètres de sortie. L’instruction ALTER PROCEDURE A provoquera une erreur lorsque la transaction sera validée.
La procédure (B) appelle la procédure (A) en lui transmettant des valeurs comme paramètres d’entrée. Aucune dépendance ne sera enregistrée dans RDB$DEPENDENCIES. Les modifications ultérieures des paramètres d’entrée de la procédure A seront autorisées. Un échec se produira au moment de l’exécution si B appelle A avec un ensemble incohérent de paramètres d’entrée.

Note

Autres commentaires

Pour les modules PSQL hérités de versions antérieures de Firebird (y compris de nombreux triggers système, même si la base de données a été créée sous Firebird version 2.1 ou ultérieure), le champ RDB$VALID_BLR est NULL. Cela ne signifie pas que leur BLR est invalide.
Les commandes SHOW PROCEDURES, SHOW FUNCTIONS et SHOW TRIGGERS de l’utilitaire de ligne de commande isql marqueront les modules d’un astérisque lors de la sortie d’informations dont le champ RDB$VALID_BLR est égal à 0. Les commandes SHOW PROCEDURE procname, SHOW FUNCTION funcname et SHOW TRIGGER trigname affichant le code du module PSQL n’alarmeront pas l’utilisateur avec un BLR invalide.

Note sur l’égalité

Important

Cette observation sur les opérateurs d’égalité et d’inégalité s’applique à tout Firebird.

L’opérateur =, qui est utilisé dans de nombreuses conditions, ne compare que des valeurs entre elles. Selon la norme SQL, NULL n’est pas une valeur et, par conséquent, deux valeurs NULL ne sont ni égales ni inégales l’une à l’autre. Si vous voulez que les valeurs NULL correspondent l’une à l’autre lorsqu’elles sont combinées, utilisez l’opérateur IS NOT DISTINCT FROM.

SELECT *
FROM A
JOIN B ON A.id IS NOT DISTINCT FROM B.code

De même, si vous voulez que les valeurs NULL soient différentes de toute valeur et que deux valeurs NULL soient traitées comme égales, utilisez l’opérateur IS DISTINCT FROM au lieu de l’opérateur <>.

SELECT *
FROM A
JOIN B ON A.id IS DISTINCT FROM B.code

Pseudo-Colonne RDB$RECORD_VERSION

Pseudo-colonne RDB$RECORD_VERSION

Champ RDB$VALID_BLR

docnext count = 2

Comment cela fonctionne

Note sur l’égalité

Pseudo-colonne `RDB$RECORD_VERSION`