FirebirdSQL logo

Informations générales

Pour commencer, lisez quelques notes sur certaines des caractéristiques sous-jacentes à l’implémentation du langage de Firebird.

SQL Sous-ensembles

SQL comporte quatre sous-ensembles de SQL utilisés dans diverses applications :

DSQL

SQL dynamique.

PSQL

SQL procédurale.

ESQL

SQL embarquée.

ISQL

SQL interactive.

Dynamic SQL est une partie essentielle du langage qui est conforme à la partie 2 (SQL/Foundation – SQL/Basics) de la spécification SQL. DSQL est une construction transmise par les applications clientes à l’aide de l’API Firebird et traitée par le serveur de base de données.

SQL procédural est une extension de Dynamic SQL, qui contient en outre des instructions composites contenant des variables locales, des affectations, des boucles et d’autres constructions procédurales. PSQL fait référence à la partie 4 (SQL/PSM) de la spécification SQL. Initialement, l’extension PSQL n’était disponible que dans des modules (procédures et déclencheurs) stockés en permanence dans la base de données, mais relativement récemment, ils sont également devenus disponibles dans Dynamic SQL (voir EXECUTE BLOCK).

Embedded SQL définit un sous-ensemble de DSQL pris en charge par Firebird GPRE. GPRE est une application de préprocesseur qui vous permet d’intégrer des constructions SQL dans votre langage de programmation immédiat (C, C++, Pascal, Cobol, etc.) et de traiter ces constructions intégrées dans les appels d’API Firebird corrects. Notez qu’ESQL ne prend en charge qu’un sous-ensemble de constructions et d’expressions DSQL.

Interactive SQL fait référence à un langage qui peut être utilisé pour travailler avec l’application de ligne de commande Firebird ISQL pour un accès interactif aux bases de données. isql est une application cliente régulière. Pour lui, le langage habituel est le langage DSQL. Cependant, l’application prend en charge quelques commandes supplémentaires.

Les sous-ensembles de langage de DSQL et PSQL sont entièrement représentés dans ce guide. De la boîte à outils, ni ESQL ni ISQL ne sont décrits séparément ici, sauf indication explicite.

SQL Dialectes

SQL Dialectes — Le dialecte SQL est un terme qui définit les fonctionnalités spécifiques du langage SQL qui sont disponibles lorsqu’il accède à une base de données. Le dialecte SQL peut être défini à la fois au niveau de la base de données et au niveau de la connexion à la base de données. Trois dialectes sont actuellement disponibles :

  • Dialect 1 est destiné uniquement à la compatibilité descendante avec les bases de données héritées des versions très anciennes d’InterBase, v.5 et inférieures. Les bases de données Dialect 1 conservent certaines fonctionnalités linguistiques qui diffèrent de Dialect 3, qui est utilisé par défaut pour les bases de données Firebird.

    • Les informations de date et d’heure sont stockées dans le fichier . Vous disposez d’un type de données identique à .DATETIMESTAMPDATE

    • Les guillemets doubles peuvent être utilisés comme alternative aux apostrophes pour séparer les données de chaîne. Ceci est contraire à la norme SQL - les guillemets doubles sont réservés à des fins syntaxiques spéciales dans SQL standard et le dialecte 3. Par conséquent, les chaînes avec des guillemets doubles doivent être évitées.

    • La précision des types de données est inférieure à celle du 3ème dialecte et si la valeur de précision est supérieure à 9, Firebird stocke ces valeurs sous forme de longues valeurs en virgule flottante.NUMERICDECIMAL

    • BIGINT n’est pas un type de données disponible.

    • Les identificateurs ne respectent pas la casse et doivent toujours suivre les règles des identificateurs habituels — voir la section Identificateurs ci-dessous.

    • Bien que les valeurs du générateur soient stockées sous forme d’entiers 64 bits, une requête client Dialect 1, par exemple, renvoie une valeur de générateur tronquée à 32 bits.SELECT GEN_ID (MyGen, 1)

  • Le dialecte 2 n’est disponible que dans la connexion client à Firebird et ne peut pas être appliqué à la base de données. Il est destiné à vous aider à déboguer en cas d’éventuels problèmes d’intégrité des données lors de la migration du dialecte 1 vers 3.

  • Dans les bases de données dialect 3 :

    • Les nombres des types de données DECIMAL et NUMERIC sont stockés sous forme de longues valeurs à point fixe (entiers évolutifs) si la précision du nombre est supérieure à 9.

    • Le type de données TIME est disponible et utilisé pour stocker la valeur de temps uniquement.

    • Le type de données DATE stocke uniquement les informations de date.

    • Le type de données BIGINT est disponible en tant que type de données entier 64 bits.

    • Les guillemets doubles peuvent être utilisés, mais uniquement pour les identificateurs sensibles à la casse, pas pour les données de chaîne.

    • Toutes les chaînes doivent être séparées par des guillemets simples (apostrophes).

    • Les valeurs du générateur sont renvoyées sous la forme d’un entier de 64 bits.

Important

Pour les bases de données et les applications nouvellement développées, il est fortement recommandé d’utiliser le 3ème dialecte. Le dialecte lors de la connexion à une base de données doit être le même que celui de la base de données. Une exception est le cas de la migration du 1er vers le 3ème dialecte, lorsque le 2ème dialecte est utilisé dans la chaîne de connexion à la base de données.

Par défaut, ce didacticiel décrit la sémantique SQL du troisième dialecte, sauf si le texte spécifie explicitement un dialecte.

Actions en cas d’erreurs

Le traitement de toute instruction est terminé avec succès ou interrompu en raison d’une erreur causée par certaines conditions. La gestion des erreurs peut être effectuée à la fois dans l’application cliente et côté serveur à l’aide de SQL.