FAQ FirebirdConsultez toutes les FAQ

Pourquoi ai-je une erreur lorsque je tente de trier en fonction d'une colonne BLOB ?

Les anciennes versions de Firebird le permettaient, mais le résultat était erroné. C'était l'ID du BLOB qui était trié, au lieu des données contenues dans le BLOB, ce qui était pratiquement inutile. Les nouvelles versions ne le permettent plus.

Il n'y a pas encore de projet pour l'ajout du tri de BLOBs. Le principal problème est que l'espace de tri d'un enregistrement est limité à 64kB. Cette limite pourrait être levée avec Firebird 3.
Traduction réalisée depuis http://www.firebirdfaq.org/faq58/

Si vous avez installé différentes versions de Firebird il est possible que votre client n'ait pas le bon fichier messages.
Le fichier messages contient le texte des messages pour chaque code erreur. En cas d'erreur, le serveur envoie le code et le client utilise le fichier des messages pour vous fournir un texte compréhensible.
Cependant, si le fichier des messages n'est pas de la même version, l'index est modifié et vous obtiendrez un message hors sujet.

Le fichier des messages est nommé firebird.msg et situé dans le répertoire d'installation de Firebird. Essayez d'installer la même version entre le client et le serveur pour résoudre ce problème.
Traduction réalisée depuis http://www.firebirdfaq.org/faq70/

Il y a beaucoup de raisons possibles. La plupart viennent du fait que certaines opérations nécessitent l'accès exclusif à la base de données (Comme l'ajout de clé étrangère dans les anciennes versions de Firebird).
Étapes à essayer :

• Validez (COMMIT) toutes vos transactions et essayez
• Si cela ne fonctionne pas : Déconnectez tous les autres utilisateurs et essayez. Si vous utilisez le mode Super serveur vous pouvez vérifier quels autres utilisateurs sont connectés avec un outil d'administration.
• Si cela ne fonctionne pas : Déconnectez vous également, Reconnectez vous et essayez.
• Si cela ne fonctionne pas : Éteignez l'ordinateur et allez vous coucher. Un esprit dispos trouve des solutions plus rapidement
  

Vous pouvez obtenir cette erreur en essayant de créer un nouveau rôle. Les rôles et nom d'utilisateurs utilisant le même espace, vous ne pouvez pas avoir un rôle ayant le même nom qu'un utilisateur.
La partie épineuse de ce problème est que Firebird ne stocke pas les noms d'utilisateurs dans les bases de données, il scrute la table des privilèges pour vérifier si les privilèges pour un utilisateur existent (et alors en conclut que cet utilisateur existe).
Si vous êtes sûr que l'identification utilisateur n'existe plus, révoquer tous ses privilèges avant de créer le rôle. Pour découvrir quels sont ces privilèges, vous pouvez faire une requête sur la table RDB$USER_PRIVILEGES :

1
2
3
SELECT * 
FROM RDB$USER_PRIVILEGES 
WHERE RDB$USER = 'le_nom_de_role_à_créer'

Tentative de stocker une valeur déjà existante (selon les transactions actives) dans un index unique "RDB$INDEX_XYZ".

Cette erreur arrive lorsque vous essayez de créer une colonne de table ou de vue avec un nom déjà existant.
C'est un problème courant, lorsque créez des vues sans fournir de nom de colonnes explicitement et que vous n'utilisez pas d'alias de colonne dans le SELECT sous-jacent. Nommer les colonnes de manière explicite règlera le problème.
Traduction réalisée depuis http://www.firebirdfaq.org/faq319/

Complément du message: Obtenu :32779. Prévu : 10 ("Unsupported on-disk structure...")

Cette erreur peut se produire dans trois cas :

1. Vous essayez d'accéder à une base de données non Firebird. Les bases de données InterBase ont une structure quasi identique, mais celles de version supérieures à 6.0 ne sont pas reconnues par le serveur Firebird.

2. Vous essayez d'accéder à un fichier de base de données d'une version supérieure à celle du serveur Firebird. Par exemple, vous avez créé une base avec Firebird 2.0, et vous essayez avec un serveur Firebird 1.5 (ou un client embarqué).
Dans ce cas , et si vous avez besoin d'accéder aux données avec la vieille version vous devrez faire les choses suivantes :

• Installez la vieille version de Firebird et créer avec une base vide. Cette base vide aura un ODS inférieur . Ceci dans le but d'avoir deux fichiers de base de données pouvant être utilisés par les deux versions de Firebird. La base vide devra avoir la même structure (tables, procédures, etc.) que la pleine. Si vous n'avez pas accès à la structure de la base de données, vous pouvez toujours l'extraire en utilisant l'outil ISQL (avec l'option -x) ou un outil d'administration graphique (option 'Extract Metadata DLL' dans FlameRobin). Si vous utilisiez des fonctionnalités seulement disponibles dans la nouvelle version de Firebird, vous serez obligé de modifier le script SQL pour que cela fonctionne avec l'ancienne version.
• Installez la nouvelle version de Firebird et copiez toutes les données vers la base vide Cette opération nécessite la version du serveur Firebird la plus récente car seule celle-ci peut reconnaitre la structure sur disque des deux bases. Pour faire la copie vous pouvez utilisez un outil de pompage de données comme IB Data Pump ou FBCopy (FBCopy a une option très utile de désactivation de tous les triggers au cours de la copie des données et peut aussi copier les générateurs).
• Une fois la copie faite vous aurez une base de données avec l'ancienne ODS et toutes vos données à l'intérieur. Vous pourrez alors réinstaller l'ancienne version de Firebird et continuer de travailler avec.
  

Chaque changement que vous faites dans la structure d'une table est enregistré dans la table système RDB$FORMATS. Quand vous faites 255 changements, vous devez faire un backup suivi d'une restauration,réinitialisant les compteurs de toutes les tables.
Pourquoi l'enregistrement de ces changements est-il nécessaire ? Eh bien, imaginons que vous ayez une colonne de table de type INTEGER, et que vous la changiez en DECIMAL(16,2). Lorsque ceci se passe, vous pouvez avoir des milliers ou millions d'enregistrements dans cette table. La représentation interne (binaire) de ces deux types n'est pas la même, cela impliquerait donc que Firebird devrait réécrire tous ces enregistrements. Au lieu de cela, Firebird se souvient que les anciens enregistrements ont le format INTEGER et les convertit à la volée pendant la lecture. Les nouveaux enregistrements, eux, étant stockés au format DECIMAL(16,2).
Traduction réalisée depuis http://www.firebirdfaq.org/faq239/

- La taille de la clé dépasse les restrictions de mise en oeuvre pour l'index XYZ
- Taille de la clé trop grosse pour l'index XYZ

Firebird a une taille limite en ce qui concerne les index , et les contraintes de clés primaires , uniques ou étrangères utilisent des index pour faire les contrôles .
Traduction réalisée depuis http://www.firebirdfaq.org/faq212/ et http://www.firebirdfaq.org/faq213/.

C'est un bug connu avec le jeu de caractères UNICODE_FSS. Veuillez bien utiliser Firebird 2.0 et le jeu de caractères UTF8.
Traduction réalisée depuis http://www.firebirdfaq.org/faq72/

1
2
3
Unable to complete network request to host XYZ.<br/> 
Failed to locate host machine. <br/> 
The specified name was not found in the hosts file or Domain Name Services.<br/>

ping XYZ

• Utilisez l'adresse IP au lieu du nom d'hôte dans la chaine de connexion
• Editez les fichier 'hosts' et ajoutez la ligne appropriée pour l'hôte. Exemple: 192.168.0.22 XYZ
• Contactez votre administrateur réseau pour savoir pourquoi la résolution DNS ne fonctionne pas.
  

car dérivant d'une fonction SQL ou d'une expression.
Tentative de mettre à jour une colonne en lecture seule.

Cette erreur peut survenir quand vous essayez de mettre à jour une colonne calculée. Comme celle-ci est calculée, vous ne pouvez écrire aucune valeur directement à l'intérieur. Si vous voulez vraiment une valeur particulière, vous devrez modifier les colonnes composant le calcul.

Cette erreur arrive également quand vous essayez de modifier une valeur d'une variable NEWou OLD dans un trigger. Le problème est mis en évidence à partir de la version Firebird 2.0 , alors que les versions antérieures ignoraient de manière silencieuse de telles erreurs de logique.

Exemple incluant une mise à jour d'une variable OLD.quelquechose dans un trigger INSERT , ou NEW.quelquechose d'un trigger DELETE.
Dans cet exemple nous avons un trigger multi-action, ce qui nécessite de vérifier les variables de contexte : DELETING ou INSERTING pour connaitre l'opération qui a déclenché le trigger.

1
2
3
4
5
6
7
8
CREATE TRIGGER ... 
ACTIVE BEFORE INSERT OR UPDATE OR DELETE ... 
AS 
BEGIN 
IF (INSERTING) THEN NEW.quelquechose = 10; 
if (DELETING AND OLD.quelquechose = 10) then ... 
etc.... 
END

Les erreurs telles que 'INET/inet_error: read errno = ' sont des erreurs réseau.

Voici une liste des erreurs Linux et leurs significations :

... et mot de passe ne sont pas définis. Demandez à votre administrateur de base de données de créer un identifiant Firebird.

Vous aurez cette erreur si vous essayez de vous connecter avec un nom d'utilisateur ou un mot de passe incorrect.
Si vous essayez de vous connecter à un fichier base de données directement (c'est à dire sans le préfixe de nom d'hôte) alors vous avez probablement indiquer les paramètres -user et -pass, mais ils ne sont pas requis.
Si vous venez juste d'installer Firebird et que l'installateur ne vous a pas demander de mot de passe , alors vous risquer de passer longtemps à le chercher. Le nom d'utilisateur par défaut est SYSDBA, qui veut dire SYStem DataBase Administrator, le mot de passe par défaut étant : masterkey.

Note: en fait, le mot de passe par défaut est 'masterke', car seuls les 8 premiers caractères sont significatifs.

Sur quelques installations Linux, un mot de passe aléatoire est généré par le système au cours de l'installation. Vous pourrez le retrouver dans le répertoire d'installation (par défaut /opt/firebird).

Traduction réalisée depuis http://www.firebirdfaq.org/faq135/

Cette erreur arrive lorsque vous perdez la connexion au serveur Firebird. Les causes les plus courantes étant :

• Quelqu'un a redémarré le serveur Firebird
• Le serveur Firebird a planté
  

Si vous obtenez un message d'erreur quelconque commençant par "Parsing Error", ce n'est probablement pas une erreur renvoyée par Firebird, mais plutôt par l'outil d'administration que vous utilisez.
Quelques outils (tel IBExpert ou EMS) essayent d'être intelligents et analysent vos instructions avant même de les envoyer à Firebird. Cependant, ils le font quelquefois de manière incorrecte, car les analyseurs ne sont pas génériques et butent souvent sur les nouveautés de Firebird.
Assurez-vous donc d'utiliser un outil avec un analyseur de syntaxe générique (ISQL ou FlameRobin) avant de rapporter l'erreur à l'équipe de Firebird. Et utilisez toujours la dernière version disponible de l'outil car le bug a probablement déjà été découvert par un autre utilisateur et corrigé.
Traduction réalisée depuis http://www.firebirdfaq.org/faq38/

Votre base de données est probablement arrêtée. Pour le vérifier exécutez :

gstat -header /path/to/database.fdb

Attributes force write, database shutdown

gfix -online /path/to/database.fdb

Cette erreur veut généralement dire que le serveur Firebird ne peut pas ouvrir le fichier base de données. Soit vous (la chaine de connexion ne contient que le chemin du fichier) soit le serveur Firebird (quand la chaine de connexion est préfixée par un nom d'hôte) n'ont pas les droits d'accès suffisant sur le fichier base de données ou le répertoire le contenant. Donc, vérifiez les privilèges (propriétaire de fichier et permissions) sur le fichier base de données et réglez les.
Traduction réalisée depuis http://www.firebirdfaq.org/faq264/

Ce message apparait lorsque vous essayez de changer un mot de passe sur une base de données Firebird 2.0 en utilisant une méthode dépréciée accédant au fichier sécurité directement. Firebird 2.0 empêche cela, pour des problèmes de sécurité. La seule manière de modifier les mots de passe c'est via les API Services. Utilisez l'interface approprié fourni par votre bibliothèque de connexion.

Autre alternative utilisez l'outil de Firebird GSEC

gsec -database path -mo username -pw new_password -user sysdba -pass masterkey

/opt/firebird/bin/gsec -database localhost:/opt/firebird/security.fdb -mo sysdba -pw monmdp -user sysdba -pass masterkey

"Multiple rows in singleton select"

Cette erreur apparait quand vous avez une instruction SQL qui doit obtenir une seule valeur mais en obtient plusieurs. Voici un exemple :

1
2
3
SELECT * 
FROM employee e 
WHERE e.emp_no = (SELECT p.emp_no FROM employee_project p);

1
2
3
SELECT * 
FROM employee e 
WHERE e.emp_no = (SELECT FIRST 1 p.emp_no FROM employee_project p);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SELECT * 
FROM employee e 
WHERE e.emp_no IN (SELECT p.emp_no FROM employee_project p); 
  
-- Ou , plus efficacement : 
  
SELECT * 
FROM employee e 
WHERE EXISTS (SELECT 1 FROM employee_project p WHERE e.emp_nO = p.emp_no); 
  
-- Ou, encore mieux : 
  
SELECT e.* 
FROM employee e 
JOIN employee_project p ON e.emp_nO = p.emp_no;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SELECT e.* 
FROM employee e 
WHERE e.emp_no IN (SELECT p.emp_no FROM employee_project p WHERE p.proj_id= 8); 
  
-- Ou , plus efficacement : 
  
SELECT e.* 
FROM employee e 
WHERE EXISTS (SELECT 1 FROM employee_project p WHERE p.proj_id= 8 AND p.emp_no = e.emp_no); 
  
-- Qui peut être aussi écrit : 
  
SELECT e.* 
FROM employee e 
JOIN employee_project p on p.emp_no = e.emp_no 
WHERE p.proj_id = 8;

"Malformed string"

Si vous voyez cette erreur, cela veut dire, dans la plupart des cas, que le client n'est pas capable de transformer la chaine écrite en un jeu de caractères acceptable pour le serveur Firebird. Voici une courte explication de fonctionnement :

Dans votre programme client vous écrivez un texte, qui est alors affiché à l'écran. Ce texte a le même jeu de caractères que le reste de votre environnement. Généralement UTF8 sous Linux, et un jeu WIN-xxxx sous Windows (WIN-1252 pour l'Europe de l'ouest, WIN-1250 pour l'Europe de l'est, etc....).
Votre outil client doit alors le translittérer vers le jeu de caractères de votre connexion Firebird, puis le serveur Firebird translittère ceci dans le jeu de caractères de la colonne qui va recevoir le texte dans la base de données.
Si votre outil client n'est pas assez 'intelligent' pour faire la translittération, vous devrez faire en sorte que le jeu de caractères de la connexion soit le même que celui de votre environnement.

Par exemple, si vous utilisez ISQL et avez un Windows d'Europe de l'ouest, vous devrez tapez ceci au début de votre session ISQL :

SET NAMES WIN1252;

"Lock conflict on no wait transaction"

Ce n'est pas une erreur, mais une exception normale provoquée par la gestion des transactions. Vous aurez ce message quand une transaction tente de mettre à jour ou supprimer un enregistrement modifié par une autre transaction plus récente.
Cela n'arrive que si la transaction en cours est une transaction 'NO WAIT', car elle n'attend pas que les autres transactions aient fini, mais plutôt rapporte l'erreur et s'arrête immédiatement.

Notez que c'est un évènement normal dans le cas de transactions 'NO WAIT' et que c'est votre application qui doit être prête à ce genre de cas et capable de le gérer.
Ceci est nécessaire pour maintenir la consistance de la base.

Imaginez, par exemple, que vous avez une table avec l'enregistrement

1
2
3
ID VALEUR 
-- ----- 
10 15000

UPDATE t1 SET valeur = valeur + 20 WHERE id = 10;

Vous obtiendrez souvent cette erreur en créant des vues avec unions. La raison en est que Firebird est très strict avec les types de données, et si vous avez différents types de données pour une même colonne dans des requêtes d'UNION il renvoie une erreur.
Cela arrive même si la différence est minime comme par exemple CHAR(5) vs CHAR(6). Cela arrive aussi entre les types DECIMAL et DOUBLE, et (une des plus embêtantes) entre NULL et zéro. Exemples avec la base de données Employee.fdb:

1
2
3
4
5
6
7
8
9
10
11
CREATE VIEW extreeme_employee (first_name, job_grade) 
AS 
SELECT 'Confidentiel', job_grade 
FROM employee 
WHERE job_grade = (SELECT MAX(job_grade) FROM employee) 
  
UNION 
  
SELECT first_name, job_grade 
FROM employee 
WHERE job_grade = (SELECT MIN(job_grade) FROM employee);

1
2
3
4
5
6
7
8
9
10
11
CREATE VIEW extreeme_employee (first_name, job_grade) 
AS 
SELECT first_name, job_grade 
FROM Employee 
WHERE job_grade = (SELECT MAX(job_grade) FROM employee) 
  
UNION ALL 
  
SELECT first_name, 0 
FROM employee 
WHERE job_grade = 0;

... en utilisant le chemin du fichier de base de données

Réponse Windows :
La raison c'est que le mode Classique sur Windows travaille toujours via la pile TCP/IP, vous devez spécifier le nom de l'hôte ou son adresse IP dans la chaine de connexion, même si c'est localhost.
Utilisez :

localhost:C:\Chemin\vers\base.fdb

C:\chemin\vers\base.fdb

"Deadlock. Update conflicts with concurrent update."

Ceci arrive lorsque votre transaction essaye de mettre à jour ou effacer un enregistrement qu'une autre transaction a mis à jour ou effacé.
C'est un évènement normal dans le monde des bases de données et votre application doit être capable de le régler.
Ce 'problème' est facilement reproductible, pour vous 'amuser' . Ouvrez deux sessions ISQL, exécutez la même requête de mise à jour puis essayez de valider les deux transactions.

Notez toutefois que le problème n'est pas toujours aussi facile à résoudre, car il peut y avoir des procédures stockées ou des triggers impliqués qui font des mises à jour sur des tables à certains moments.
Si vous avez des difficultés à cerner le problème, ajouter quelques requêtes de traçage via des tables externes (qui ne sont pas concernées par le contrôle des transactions) peut aider.

Si vous avez construit votre système de telle façon que les Étreintes fatales soient fréquentes, considérez l'utilisation des transactions NO WAIT, ainsi vous obtiendrez l'erreur instantanément sursoyant ainsi au délai d'attente pour les étreintes fatales.
Si vous considérez les étreintes fatales comme un problème que vous ne pouvez résoudre, choisissez un mode d'isolation de transaction différent pour votre application.

Traduction réalisée depuis http://www.firebirdfaq.org/faq151/

"Can't format message nn:mmm -- message text not found"

Cela veut dire que le fichier messages firebird.msg sur le client n'est pas trouvé ou d'une version différente de celle du serveur.
C'est dû à la manière dont les messages d'erreur sont fournis par Firebird . Quand une erreur se produit, le serveur envoie le code erreur au client. Le client recherche alors dans le fichier Firebird.msg sur le disque dur local et récupère le texte du message tel qu'il sera présenté à l'utilisateur.

Cela permet à de nombreux clients d'avoir des messages en différentes langues (par exemple, quatre clients utilisant le même serveur Firebird peuvent avoir les messages d'erreur en Anglais, Français, Espagnol et Allemand).

Quand de nouvelles versions de Firebird sont mises à disposition, des messages d'erreurs peuvent être ajoutés, modifiés ou supprimés. Si vous avez un client avec une version différente du serveur auquel il est connecté, vous pouvez avoir des messages 'bizarres' (code erreur modifié), ou un avertissement indiquant que le texte du message n'est pas trouvé.

Pour réparer cela , assurez vous que le client et le serveur sont de la même version.
Traduction réalisée depuis http://www.firebirdfaq.org/faq288/

"Implementation limit exceeded. Block size exceeds implementation restriction"

Cela veut dire que votre instruction SQL a dépassé les limites de taille d'une instruction SQL. La limite est de 64kB pour les instructions texte, 64 Kb pour les BLR compilés et de 48kB pour les plans d'exécution.
Si toutefois la taille de votre instruction était inférieure à 64Kb, il y a quelque chose à regarder :
Si vous utilisez IN essayez de le convertir en EXISTS car IN est converti en un ensemble d'instructions OR en interne.
Si vous faites une jointures entre vues, elles-mêmes étant un résultat d'UNIONs, le plan peut être énorme et complexe. Essayez alors d'écrire des vues ne couvrant réellement que vos besoins pour cette requête.
Si rien de cela fonctionne, peut-être pouvez vous scinder votre requête en plusieurs sous-requêtes, ou écrire une procédure stockée pour faire une partie du travail.
Traduction réalisée depuis http://www.firebirdfaq.org/faq299/

Vous allouez, probablement, de la mémoire sans la libérer. Firebird ne connait rien à l'allocation de mémoire Delphi ou autre que vous utilisez.
Si votre UDF retourne un résultat chaine, vous devez toujours utiliser ib_util_malloc() pour allouer la mémoire pour ce résultat.
L'UDF doit être déclarée en FREE_IT, de telle manière que Firebird libère la mémoire après avoir lu la chaine.

Pour utiliser ib_util_malloc(), vous devez l'importer de ib_util.dll dans votre programme, et assurez vous bien de l'utiliser en lieu et place des fonctions d'allocation de mémoire 'normales'.
exemple Delphi :

1
2
3
4
5
6
7
8
9
10
function ib_util_malloc(l: integer): pointer; cdecl; external 'ib_util.dll'; 
  
function ChangerMaChaine(const p: PChar): PChar; cdecl; 
var 
s: string; 
begin 
  s := FaireQuelquechose(string(p)); 
  Result := ib_util_malloc(Length(s) + 1); 
  StrPCopy(Result, s); 
end;

1
2
3
4
DECLARE EXTERNAL FUNCTION F_ChangerMaChaine 
CString(255) 
RETURNS CString(255) FREE_IT 
ENTRY_POINT 'ChangeMaChaine' MODULE_NAME '......'

C'était un bogue connu des versions anciennes (1.5, 2.0 RC1) de Firebird permettant une telle situation si la table était effacée (DROP) puis récréée dans la même transaction.
Le problème est corrigé, donc assurez vous de bien utiliser la dernière version stable. Plus d'informations :
http://tracker.firebirdsql.org/browse/CORE-104

Traduction réalisée depuis http://www.firebirdfaq.org/faq221/

Vous avez probablement atteint la limite restrictive d'une table qui est d'environ 70 millions de kB, incluant les enregistrements récents et les versions anciennes (sans compter les BLOBs).
Un cycle backup/restauration corrigera le problème temporairement , car effaçant les anciennes versions d'enregistrements. Pour réparer ceci à plus long terme, vous devrez soit déplacer certains enregistrements dans une autre table soit utiliser Firebird 2 si vous utilisez encore Firebird 1.x.
Traduction réalisée depuis http://www.firebirdfaq.org/faq307/

"Invalid aggregate reference"

Vous obtiendrez cette erreur si vous essayez de faire référence à un agrégat dans la clause WHERE. Par exemple:

1
2
3
4
SELECT id, MAX(date_modification) 
FROM t1 
WHERE MAX(date_modification) > current_timestamp 
GROUP BY id;

1
2
3
4
SELECT id, MAX(date_modification) 
FROM t1 
GROUP BY id 
HAVING MAX(date_modification) > current_timestamp;

Le résultat d'une opération sur un entier a fait que le bit le plus significatif a disparu.

Explication courte:

Si vous utilisez des types de données à précision fixe (smallint, integer, bigint, decimal and numeric), il est possible que le résultat du calcul ne puisse être contenu dans le type de donnée. Essayez en transtypant (CAST) les valeurs des expressions complexes en double précision pour voir si l'erreur persiste. Si cela fonctionne et que vous n'avez pas besoin d'un résultat trop précis, vous pouvez le laisser ainsi. Dans le cas contraire vous devrez vérifier chaque opération et calculer le résultat.

Détails:

Voici un exemple: si vous multipliez 9.12 par 8.11 (tous les deux déclarés NUMERIC(18,2)) vous obtiendrez 73.9632.
Si Firebird doit le stocker dans un type de données NUMERIC(18,2), nous perdrons 0.0032. Cela peut paraitre peu, mais pour des calculs compliqués, vous pouvez facilement perdre des milliers (dollars ou euros). C'est pour cela que le résultat est renvoyé sous la forme d'un NUMERIC(18,4).

Ces problèmes sont rarement visibles avec des précisions aussi faibles que 2. Essayons avec une précision plus importante. Par exemple, NUMERIC(18,6) * NUMERIC(18,6)fourniras une résultat NUMERIC(18,12), voulant dire ainsi que la valeur maximum stockable sera de 9223372.036854775807.
Si (par exemple) vous voulez garder une précision de 6 chiffres, vous pourriez faire ainsi :

CAST(valeur1 AS NUMERIC(18,3)) * CAST(valeur2 AS NUMERIC(18,3))

CAST(CAST(valeur1 AS DOUBLE PRECISION) * CAST(valeur2 AS DOUBLE PRECISION) AS NUMERIC(18,6))

"Index X is corrupt (missing entries) in table XYZ (144)"

Cela veut dire qu'il y a un problème avec le énième index de la table XYZ, c'est à dire qu'il y a des enregistrements dans cette table XYZ, mais qu'ils ne sont pas présents dans l'index.
Vous devrez d'abord essayer de reconstruire l'index. Retrouvez son nom dans la table RDB$INDICES puis exécutez

1
2
ALTER INDEX [index name] INACTIVE; 
ALTER INDEX [index name] ACTIVE;

Notez que cette erreur 10038 n'est pas un code d'erreur Firebird, mais un de la couche réseau TCP/IP.

Voici quelques cas connus où cela arrive :

1. Bug RAS Windows qui désactive une section entière d'adresses IP. La correction est fournie par Microsoft
http://support.microsoft.com/default...b;en-us;884020

2. Quelques logiciels AdWare ou pare-feu installent des moniteurs de réseau restant actifs même une fois désinstallés. Il existe un petit utilitaire permettant de faire le ménage :
http://www.snapfiles.com/get/winsockxpfix.html

Traduction réalisée depuis http://www.firebirdfaq.org/faq4/

C'est généralement le symptôme de manipulateurs de transactions non libérés après qu'elles soient terminées.
Si vous programmez directement avec les API C Firebird, vérifiez votre code.
Autrement cela peut être dû à un bogue de la bibliothèque de connexion que vous utilisez.

Quand vous créez un nouveau manipulateur de transaction, Firebird alloue un peu de mémoire pour garder des informations sur la transaction et la garde allouée jusqu'à ce que le manipulateur soit libéré. Quand vous vous déconnectez, tous les manipulateurs liés à cette connexion sont libérés automatiquement.

Un problème identique peut arriver avec des manipulateurs d'instructions non libérés.

Traduction réalisée depuis http://www.firebirdfaq.org/faq118/

Normalement l'installation de Firebird ajoute le service gdb_db à votre système. Cependant, si vous faites l'installation manuellement, ou n'avez pas les droits d'accès suffisants ou si un autre logiciel le supprime, il peut arriver que le service gdb_db ne soit pas défini.
Cela peut également arriver si vous essayez d'accéder à Firebird à partir d'une autre machine.

Pour résoudre ceci sous Windows, ajoutez la ligne suivante au fichier "%windir%\system32\drivers\etc\services" :

gds_db 3050/tcp fb #Firebird

gds_db 3050/tcp # Firebird

"Expected end of statement, encountered EOF"

Cela arrive lorsque vous importez un fichier contenant des instructions SQL dans ISQL. Lorsque vous utilisez -i ou 'in' pour importer le fichier, c'est comme si vous tapiez vous-même le contenu dans ISQL.
Par exemple, ceci est une instruction correcte:

INSERT INTO t1(x) VALUES (10)

INSERT INTO t1(x) VALUES (10);

1
2
INSERT INTO t1(x) VALUES (10); 
COMMIT;

- Ligne X, char Y FIRST

Vous obtiendrez ce message d'erreur si vous essayez de créer une vue utilisant la clause FIRST dans votre SELECT. Quelque chose comme:

1
2
3
4
CREATE VIEW EV(EMP_NO) 
AS 
SELECT FIRST 10 EMP_NO 
FROM EMPLOYEE;

"Error on main_port, shutting down"

Ce problème est spécifique au Super-Serveur. Cela arrive généralement quand un des ordinateurs client se 'plante' au milieu d'un envoi d'un quelconque 'gros paquet', laissant la connexion en attente. Le "gros paquet" pouvant être une instruction SQL très longue ou des données (importants VARCHARs ou BLOBs) dont la taille est plus grosse que la taille d'un paquet du protocole de transfert réseau (TCP/IP ou NetBEUI).
Quand ceci arrive, le Super-serveur continue d'attendre cette connexion pour finir d'envoyer les données et blocs aux autres liens. A la fin le délai d'attente sera dépassé (ce qui par défaut est fixé à deux heures), Entre temps toutes les autres connexions auront dépassé le délai d'attente.

Des corrections ont été apportées dans Firebird 2 et plus. Si vous utilisez 1.x vous devriez soit mettre à jour vers une version plus récente, soit utiliser le mode Classique pour éviter ceci - ou redémarrer le serveur Firebird quand vous voyez qu'il est bloqué.
Traduction réalisée depuis http://www.firebirdfaq.org/faq253/

"Collation unicode for character set utf8 is not installed"

Vous pouvez obtenir cette erreur quand vous essayez d'utiliser une base de données créée avec un serveur Firebird utilisant une version de bibliothèque ICU, sur un autre serveur Firebird utilisant une version différente de cette bibliothèque.
Si vous téléchargez la même version (exemple : 2.1.1) de l'installateur à partir du site web de Firebird, alors la même version de l'ICU sera utilisée pour toutes les plate-formes majeures.
Cela veut dire que si vous créez une base de données sous Windows en utilisant Firebird 2.1.1 et que vous la copiez sur une machine Linux exécutant Firebird 2.1.1 cela fonctionnera.
Cependant, beaucoup de distributions Linux fournissent les paquetages Firebird à partir de leur dépôt, et quelquefois la version de l'ICU utilisée est différente. Dans un tel cas vous devrez faire un backup de la base de données, suivi d'une restauration sur le serveur cible.(N.d.T. ce qui de toute façon est la procédure recommandée)

Vous pouvez vérifier les versions de la bibliothèque ICU avec la commande 'ldd', exemple:

1
2
3
4
dave@randoms:/opt/firebird/bin$ ldd fb_inet_server | grep icu 
libicuuc.so.30 => /opt/firebird/lib/libicuuc.so.30 (0xb787d000) 
libicudata.so.30 => /opt/firebird/lib/libicudata.so.30 (0xb7737000) 
libicui18n.so.30 => /opt/firebird/lib/libicui18n.so.30 (0xb76f9000)

"Error on main_port, shutting down"

Ce problème est spécifique au Super-Serveur. Cela arrive généralement quand un des ordinateurs client se 'plante' au milieu d'un envoi d'un quelconque 'gros paquet', laissant la connexion en attente. Le "gros paquet" pouvant être une instruction SQL très longue ou des données (importants VARCHARs ou BLOBs) dont la taille est plus grosse que la taille d'un paquet du protocole de transfert réseau (TCP/IP ou NetBEUI).
Quand ceci arrive, le Super-serveur continue d'attendre cette connexion pour finir d'envoyer les données et blocs aux autres liens. A la fin le délai d'attente sera dépassé (ce qui par défaut est fixé à deux heures), Entre temps toutes les autres connexions auront dépassé le délai d'attente.

Des corrections ont été apportées dans Firebird 2 et plus. Si vous utilisez 1.x vous devriez soit mettre à jour vers une version plus récente, soit utiliser le mode Classique pour éviter ceci - ou redémarrer le serveur Firebird quand vous voyez qu'il est bloqué.
Traduction réalisée depuis http://www.firebirdfaq.org/faq253/

Le serveur est démarré et stoppé par l'exécutable 'fbmgr' se trouvant dans le répertoire 'bin' de votre installation Firebird.
Il se nomme 'ibmgr' pour Firebird 1.0. pour démarrer le serveur tapez

/opt/firebird/bin/fbmgr -start

/opt/firebird/bin/fbmgr -start -forever

/opt/firebird/bin/fbmgr -shut -user SYSDBA -pass *****

/opt/firebird/bin/fbmgr -shut -force -user SYSDBA -pass *****