Firebird Documentation IndexFirebird 1.5 Guide de démarrage → Firebird SQL
Firebird Home Firebird Home Précédent: Effectuer une installation client-seulementFirebird Documentation IndexNiveau supérieur: Firebird 1.5 Guide de démarrageSuivant: Sauvegarde

Firebird SQL

Symbole de délimitation de chaîne de caractères
Identifiants entre guillemets doubles
Apostrophes dans les chaînes de caractères
Concatenation de chaînes de caractères
Division d'un entier par un entier
Expressions impliquant NULL

Chaque système de gestion de base de données a ses propres particularités dans la manière d'implémenter SQL. Firebird se conforme à la norme SQL plus rigoureusement que les autres SGBD à l'exception possible de son « cousin », InterBase®. Les développeurs qui migrent depuis des produits moins conformes aux normes supposent souvent à tord que Firebird est bizarre, alors que les supposées bizarreries ne sont en fait aucunement bizarres.

Symbole de délimitation de chaîne de caractères

Les chaînes de caractères dans Firebird sont délimitées par une paire de guillemets simples – 'I am a string' – (code ASCII 39, et non pas 96). Si vous utilisiez une ancienne version de Firebird proche d' InterBase®, vous pouvez vous souvenir que les guillemets simples et doubles pouvaient être utilisés indifféremment pour délimiter des chaînes de caractères. Les guillemets double ne peuvent pas être utilisés comme délimiteurs de chaîne de caractères dans des instructions SQL Firebird.

Identifiants entre guillemets doubles

Avant la norme SQL-92, il n'était pas permis d'avoir des noms d'objets (identifiants) dans une base qui étaient un des mots clè du langage, qui étaient sensibles à la casse ou contenaient des espaces. SQL-92 a introduit une règle simple pour rendre ceci possible, à la condition que les identifiants soient definis avec une paire de guillemets doubles (ASCII 34) et qu'il soit toujours fait appel à eux en utilisant des guillemets doubles.

Le but de ce « cadeau » était de faciliter la migration de métadonnées d'un SGBD non conforme à la norme à un autre la respectant. Le désavantage de ceci, est que si vous choisissez de définir un identifiant entre guillemets doubles, la sensibilité à la casse et l'usage des guillemets doubles deviennent obligatoires.

Firebird permet un léger relâchement à cette règle selon certaines conditions très limitées. Si l'identifiant qui a été défini entre guillemets doubles :

  1. a été écrit entièrement en majuscules,

  2. n'est pas un mot clé, et

  3. ne contient pas d'espaces,

... alors il peut être utilisé en SQL sans guillemet pourvu qu'il soit utilisé tout en majuscules. (Mais dès que vous mettez des guillemets doubles autour, vous devez faire attention à la casse de nouveau!)

Avertissement

Faites vraiment attention avec cela! Par exemple, si vous avez deux tables "TESTTABLE" et "TestTable", toutes deux définies avec des guillemets doubles, et que vous lanciez la commande:

SQL>select * from TestTable;

... vous obtiendrez les données de "TESTTABLE", pas de "TestTable"!

A moins que vous ayez une raison très convaincante pour définir des identifiants entre guillemets doubles, il est habituellement recommandé d'éviter cela. Firebird accepte volontiers un mélange d'identifiants entre guillemets ou non – il n'y a donc pas de problème à inclure un mot clé dont vous avez hérité d'une autre base de données, si vraiment vous en avez le besoin.

Avertissement

Certains outils d'administration de base de données appliquent systématiquement l'utilisation des guillemets doubles. Essayer de choisir un outil qui rend l'utilisation des guillemets doubles optionnelle.

Apostrophes dans les chaînes de caractères

Si vous devez utiliser un caractère apostrophe dans une chaîne de caractères, vous pouvez « vous en tirer » en précédant l'apostrophe avec une autre apostrophe.

Par exemple, cette chaîne de caractères renverra une erreur:

'Les jardins d'eden'

puisque lorsque l'analyseur syntaxique rencontrera l'apostrophe, il interprétera la chaîne de caractères comme 'Les jardins d' et ne pourra interpréter les mots suivants qui lui seront inconnus.

pour rendre cette chaîne de caractères légale, précédez l'apostrophe avec une autre apostrophe:

'Les jardins d''eden'

Notez qu'il y a DEUX simples guillemets et non un guillemet double.

Concatenation de chaînes de caractères

Avec SQL le symbole de concaténation est deux symboles « pipe » (ASCII 124, une paire sans espace). Avec SQL, le symbole « + » est l'opérateur arithmétique et causera une erreur si vous tentez de l'utiliser pour la concaténation de chaînes de caractères. L'expression suivante préfixe une colonne de type caractères avec les caractères « Rapporté par:  »:

'Rapporté par: ' || LastName

Faites attention lors de concaténations. Firebird produira une erreur si votre expression tente de concaténer deux ou plusieures colonnes de type char ou varchar qui après concaténation pourraient excéder la longueur maximum permise d'un type char ou varchar (32 Kb).

Voir aussi la note ci-dessous, Expressions impliquant NULL, à propos de la concaténation dans les expressions qui impliquent NULL.

Division d'un entier par un entier

Firebird est conforme à la norme SQL en tronquant le résultat (quotient) d'un entier par un entier au prochain entier plus petit. Cela peut donner d'étranges résultats à moins que vous soyez conscient de cela.

Par exemple, ce calcul est correct en SQL:

1 / 3 = 0

Si vous faites la mise à jour depuis un SGBD qui résoud les divisions entier/entier en un quotient de type nombre à virgule flottante (float), vous devrez modifier les expressions concernées pour utiliser un nombre à virgule flottante ou un type numérique proportionné pour le dividende, le diviseur, ou les deux.

Par exemple, le calcul ci-dessus pourrait être modifié ainsi afin de produire un résultat différent de zéro:

1.000 / 3 = 0.333

Expressions impliquant NULL

En SQL, NULL n'est pas une valeur. C'est une condition, ou un état, d'un item de données, pour lequel la valeur est inconnue. Puisque la valeur est inconnue, NULL ne peut se comporter comme une valeur. Lorsque vous tentez d'effectuer de l'arithmétique avec NULL, ou l'impliquer avec des valeurs dans d'autres expressions, le résultat de l'opération sera toujours NULL. Ce n'est pas un zéro ou un blanc ou une « chaîne vide » et ne se comporte pas comme aucune de ces valeurs.

Ainsi, voici quelques exemples du type de surprises que vous obtiendrez si vous tentez de faire des calculs ou des comparaisons avec NULL:

  • 1 + 2 + 3 + NULL = NULL

  • not (NULL) = NULL

  • 'Home ' || 'sweet ' || NULL = NULL

  • if (a = b) then
      MyVariable = 'Equal';
    else
      MyVariable = 'Not equal';

    Après l'exécution de ce code, MyVariable retournera 'Not equal' si a et b sont NULL. Cela provient du fait que l'expression 'a = b' retourne NULL si une au moins des composantes est NULL. Dans un contexte de type « if...then » , NULL se comporte comme FALSE. Donc le bloc 'then' est ignoré, et le bloc 'else' exécuté.

  • if (a <> b) then
      MyVariable = 'Not equal';
    else
      MyVariable = 'Equal';

    Ici, MyVariable retournera 'Equal' si a est NULL et b ne l'est pas, ou vice versa. L' explication est analogue à celle du premier exemple.

  • FirstName || ' ' || LastName

    retournera NULL si soit FirstName ou LastName sont NULL.

Astuce

Pensez à NULL comme étant INCONNU et tous ces étranges exemples soudainement prendront sens! Si la valeur d'un Nombre est inconnue, le résultat de '1 + 2 + 3 + Number' est aussi inconnu (et donc NULL). Si le contenu de MyString est inconnu, alors il en est de même pour 'MyString || YourString' (même si YourString est non-NULL). Etc...

Précédent: Effectuer une installation client-seulementFirebird Documentation IndexNiveau supérieur: Firebird 1.5 Guide de démarrageSuivant: Sauvegarde
Firebird Documentation IndexFirebird 1.5 Guide de démarrage → Firebird SQL