| ||
auteur : SergioMaster | ||
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/ |
| ||
auteur : SergioMaster | ||
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/ |
| ||
auteur : SergioMaster | ||
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 :
Cette erreur peut également apparaitre au cours de la restauration d'une base.(N.d.T. pas de solution miracle) La pratique recommandée est de restaurer la base sous un nom non utilisé puis de la renommée un fois la restauration complète. Traduction réalisée depuis http://www.firebirdfaq.org/faq22/ |
| ||
auteur : SergioMaster | ||
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 :
Traduction réalisée depuis http://www.firebirdfaq.org/faq297/ |
| ||
auteur : SergioMaster | ||
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/ |
| ||
auteur : SergioMaster | ||
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 :
3. Une version d'Interbase est peut-être installée. Vous devez changer la variable RemoteServicePort du fichier de firebird.conf de 3050 à une autre valeur, par exemple 3051. Assurez-vous alors d'utiliser ce n° de port dans vos chaines de connexion. Par exemple , au lieu de LOCALHOST utilisez LOCALHOST/3051, au lieu de 192.168.0.11 utilisez 192.168.0.11/3051, etc.... Note: la section 3 de cette FAQ est une contribution d'Antoine van Maarle. Traduction réalisée depuis http://www.firebirdfaq.org/faq80/ |
| ||
auteur : SergioMaster | ||
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/ |
| ||
auteur : SergioMaster | ||
- La taille de la clé dépasse les restrictions de mise en ?uvre 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/[/QUOTE] | ||
lien : ![]() |
| ||
auteur : SergioMaster | ||
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/ |
| |||
auteur : SergioMaster | |||
Vous pouvez obtenir cette erreur quand vous essayez de vous connecter à un serveur Firebird en utilisant la syntaxe hote:cheminversbase (par exemple XYZ:base.fdb), et qu'il ne peut trouver l'hôte. Si vous utilisez Delphi, et que vous venez de changer la valeur par défaut de IB_SERVER:quelquechose à IB_SERVER:autrechose, vous devez savoir que IB_SERVER doit être une hôte valide. si vous tentez de vous connecter à un serveur Firebird installé sur la même machine, remplacez IB_SERVER par LOCALHOST. Autrement, c'est probablement un problème de résolution du nom de l'hôte. Chaque nom d'hôte doit être résolu en une adresse IP pour que la connexion réussisse. Le nom de l'hôte XYZ devra être soit indiqué dans votre fichier hosts (/etc/hosts sous Linux, sous Windows c'est variable, essayez c:\windows\system32\drivers\etc\hosts) soit défini dans votre serveur DNS. Vous pouvez vérifier la résolution d'adresse en utilisant la commande 'ping' :
Si cela ne fonctionne pas , vous avez les options suivantes :
Traduction réalisée depuis http://www.firebirdfaq.org/faq136/ |
| ||
auteur : SergioMaster | ||
Vous essayez, probablement, d'utiliser un tableau comme paramètre d'une procédure stockée, ce qui n'est pas permis. Traduction réalisée depuis http://www.firebirdfaq.org/faq281/ |
| ||
auteur : SergioMaster | ||
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 NEW ou 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.
Traduction réalisée depuis http://www.firebirdfaq.org/faq331/ |
| ||
auteur : SergioMaster | ||
Cela peut paraitre étrange, mais actuellement c'est une erreur du système de fichier Linux indiquant que le disque est plein. Traduction réalisée depuis http://www.firebirdfaq.org/faq194/ | ||
lien : ![]() |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
auteur : SergioMaster | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Les erreurs telles que 'INET/inet_error: read errno = ' sont des erreurs réseau. Voici une liste des erreurs Linux et leurs significations :
Traduction réalisée depuis http://www.firebirdfaq.org/faq120/ |
| ||
auteur : SergioMaster | ||
... 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/ |
| ||
auteur : SergioMaster | ||
Cette erreur arrive lorsque vous perdez la connexion au serveur Firebird. Les causes les plus courantes étant :
Si cela arrive régulièrement lors d'une requête particulière, essayez avec la version la plus récente de Firebird. Si le problème continue, contactez les développeurs, car cela serait un bug dans Firebird. Notez que d'autres instances du serveur Firebird peuvent être disponibles quand l'une d'elles plante. Si vous utilisez le mode Super Serveur, le service entier plantera, mais sera redémarré automatiquement (soit par le Guardian Firebird soit par le système s'il est exécuté comme service système sous Windows). Si vous utilisez le mode Classique, seule une instance plantera, alors que les autres continueront à fonctionner. Dans les deux cas, le serveur Firebird est disponible aux connexions ultérieures, donc cela peut vous induire à penser que le serveur n'a pas planté. Traduction réalisée depuis http://www.firebirdfaq.org/faq96/ |
| ||
auteur : SergioMaster | ||
Généralement cela arrive lorsque vous fournissez un blob à une procédure stockée et l'utilisez dans une instruction INSERT ou UPDATE. Après l'instruction, les données du BLOB sont réécrites sur la base et l'on obtient le BLOB ID réel au lieu d'un temporaire , rendant non valide la variable d'entrée. En d'autres termes, la variable d'entrée contient alors un ID de BLOB invalide ne pointant sur rien, et vous ne pouvez plus l'utiliser. Ce problème est réglé dans les nouvelles versions de Firebird. Traduction réalisée depuis http://www.firebirdfaq.org/faq283/ |
| ||
auteur : SergioMaster | ||
Vous pouvez obtenir cette erreur lorsque vous tentez de faire un GFIX pour valider la base de données. La validation d'une base de données requière un accès exclusif pour SYSDBA ou le propriétaire de la base. Vous devez d'abord mettre la base de donnée hors ligne (également en utilisant GFIX), ce qui empêchera tout autre utilisateur de se connecter. Traduction réalisée depuis http://www.firebirdfaq.org/faq116/ |
| ||
auteur : SergioMaster | ||
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/ |
| |||
auteur : SergioMaster | |||
Votre base de données est probablement arrêtée. Pour le vérifier exécutez :
La sortie devrait contenir la ligne :
C'est une option utile lorsque vous voulez faire des modifications des méta-données et empêcher l'utilisation de la base par les utilisateurs. Pour remettre la base en ligne , tapez :
Traduction réalisée depuis http://www.firebirdfaq.org/faq246/ |
| |||
auteur : SergioMaster | |||
En général cette erreur veut dire que le serveur Firebird n'a pas pu ouvrir le fichier base de données. En voici les raisons possibles : 1. Le fichier ou le répertoire n'existe pas. Vérifiez que vous vous connectez au bon serveur (nom d'hôte ou adresse IP) et que le fichier existe vraiment. Peut-être est-ce une erreur de frappe ? Si vous êtes en train de créer une nouvelle base, le répertoire doit exister et accessible au compte qui exécute le serveur Firebird. 2. Vous ou le serveur Firebird n'avez pas de droit d'accès suffisant au fichier base de données ou au répertoire le contenant. Donc, vérifiez les privilèges (propriétaire du fichier et permissions) sur le fichier base de données et réglez les. Avertissement aux utilisateurs Linux : Il est sage de garder vos bases de données dans un répertoire avec les permissions suivantes (770 en terminologie chmod):
Si c'est une machine de développement et que vous voulez pouvoir manipuler les fichiers directement, ajoutez vous au groupe 'firebird'. Notez, qu'en général, vous devrez préalablement fermer votre session complètement avant que votre appartenance au groupe soit effective pour votre compte sous Linux. Quant aux fichiers bases de données , utilisez les privilèges suivants (660 en terminologie chmod):
Cela assurera que seul l'utilisateur firebird (celui qui exécute le serveur Firebird) et les membres du groupe firebird (administrateurs des bases sur la machine) pourront directement accéder aux bases de données. Traduction réalisée depuis http://www.firebirdfaq.org/faq102/ |
| ||
auteur : SergioMaster | ||
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/ | ||
lien : ![]() |
| ||
auteur : SergioMaster | ||
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
Par exemple pour changer le mot de passe de SYSDBA de "masterkey" à "monmdp" sous LINUX
Traduction réalisée depuis http://www.firebirdfaq.org/faq23/ |
| ||||
auteur : SergioMaster | ||||
"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 :
Cela ne peut fonctionner car la sous-requête renvoie plusieurs valeurs pour p.emp_no et Firebird ne peut décider laquelle utiliser. Ceci arriverait même si toutes les valeurs étaient identiques. Vous devez décider de ce que vous voulez vraiment faire et réécrire la requête. Par exemple si nous voulions : Avoir un employé par projet
Tous les employés ayant un projet
Les employés d'un projet particulier :
Traduction réalisée depuis http://www.firebirdfaq.org/faq171/ |
| ||
auteur : SergioMaster | ||
"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 :
Ainsi , vous pourrez travailler avec des bases UTF8 avec ISQL. Quelques outils (comme, par exemple, FlameRobin) sont plus avancés et font les translittérations nécessaires à votre place , ainsi vous pouvez utiliser un jeu de caractères de connexion (par exemple UTF8) sans problème. Traduction réalisée depuis http://www.firebirdfaq.org/faq342/ |
| ||
auteur : SergioMaster | ||
"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
Maintenant, nous avons deux transactions démarrant approximativement au même moment, les deux faisant :
Vous pourriez vous attendre à ce que la colonne contienne la valeur 15040 après que les deux aient été validées . Mais voyons ce qui se passe réellement dans la base de données. La transaction 1 lit la valeur 15000 , ajoute 20 et met 15020 - sans valider pour l'instant, mais fait autre chose . La transaction 2 démarre, lit 15000 dans la colonne (la transaction 1 , n'ayant pas encore été validée), ajoute 20 et inscrit 15020. Si aucune erreur n'était rapportée , vous finiriez avec la valeur 15020 au lieu de 15040 dans la colonne. Cependant l'exception aura été levée. Si c'est une transaction de type NO WAIT, le message aurait été envoyé de suite. D'un autre coté, une transaction de type 'WAIT' aurait attendu que la première transaction finisse avant d'aller plus loin (si la première était retournée en arrière 'roll back') ou renvoyer une erreur (si la première avait été validée). Lorsque vous obtenez de tels messages, cela aide souvent de changer les transactions de 'NO WAIT' à 'WAIT', bien que vous deviez enquêter très sérieusement sur la cause car une mauvaise gestion des transactions peut amener à de pauvres performances. Traduction réalisée depuis http://www.firebirdfaq.org/faq109/ |
| ||
auteur : SergioMaster | ||
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:
ou :
La solution c'est de transtyper (CAST) la valeur dans le bon type de données, de façon à ce que toutes les requêtes renvoient le même type de donnée par colonne. Firebird 2 a une meilleure résolution de type et détecte le type de donnée le plus important, et permet aux plus petits de s'y ajuster, par exemple vous avez CHAR(5) dans une requête et CHAR(6) dans une autre, Firebird mettra automatiquement le colonne de la vue à CHAR(6). Notez ,toutefois , que les types de donnée doivent être compatibles (par exemple , vous ne pourrez pas faire l'union d'un BLOB et d'un DECIMAL). Traduction réalisée depuis http://www.firebirdfaq.org/faq92/ |
| ||
auteur : SergioMaster | ||
... 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 :
à la place de :
Réponse Linux : Vous n'avez probablement pas les permissions de lecture écriture sur le fichier base de données. Vous nécessitez la permission d'écriture car la base de données est modifiée à chaque transaction (et vous ne pourrez rien faire sans transaction). Traduction réalisée depuis http://www.firebirdfaq.org/faq15/ |
| ||
auteur : SergioMaster | ||
"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/ |
| ||
auteur : SergioMaster | ||
"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/ |
| ||
auteur : SergioMaster | ||
"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/ | ||
lien : ![]() |
| ||
auteur : SergioMaster | ||
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 :
Déclaration dans Firebird:
Traduction réalisée depuis http://www.firebirdfaq.org/faq82/ |
| ||
auteur : SergioMaster | ||
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/ |
| ||
auteur : SergioMaster | ||
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/ |
| ||
auteur : SergioMaster | ||
"Invalid aggregate reference" Vous obtiendrez cette erreur si vous essayez de faire référence à un agrégat dans la clause WHERE. Par exemple:
Vous devez faire référence aux agrégats dans la clause HAVING :
Traduction réalisée depuis http://www.firebirdfaq.org/faq115/ |
| ||
auteur : SergioMaster | ||
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 :
ce qui vous fournira un résultat NUMERIC(18,6), mais il est fort possible que vous obtiendrez un résultat plus juste en transtypant vers un double:
De même, si vous avez un mélange de multiplications et divisions il peut être utile de changer l'ordre des opérations pour éviter l'erreur de débordement. Traduction réalisée depuis http://www.firebirdfaq.org/faq207/ |
| ||
auteur : SergioMaster | ||
"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
-- De fait, avec les nouvelles versions de Firebird seule la dernière instruction, activer l'index, suffit. Si c'est fréquent, ou que vous ne pouvez pas reconstruire l'index, assurez vous que votre base de données est en écritures forcées (forced writes) et vérifiez les possibilités de problèmes CPU, mémoires, disques durs ou d'un arrêt provisoire du système de cache des fichiers ayant provoqué la corruption de la base de données. Vous pouvez aussi utiliser l'application IBFirstAid de IBSurgeon pour obtenir un diagnostic. Traduction réalisée depuis http://www.firebirdfaq.org/faq275/ |
| ||
auteur : SergioMaster | ||
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.aspx?scid=kb;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/ |
| ||
auteur : SergioMaster | ||
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/ |
| ||
auteur : SergioMaster | ||
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" :
%windir% étant le répertoire d'installation de votre Windows, par exemple C:\WINNT. Sous Linux, ajoutez la ligne suivante au fichier "/etc/services" :
Vous aurez peut être besoin de redémarrer l'application ayant rapporter l'erreur après ces changements. Prenez bien note que vous devez ajouter cette ligne sur l'ordinateur où l'erreur a eu lieu. Traduction réalisée depuis http://www.firebirdfaq.org/faq227/ |
| |||
auteur : SergioMaster | |||
"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:
Si vous sauvegardez ceci dans un fichier et que vous l'importez dans ISQL, vous obtiendrez l'erreur. Imaginez que vous tapiez ceci manuellement dans ISQL, ce dernier attendrait gentiment d'autres entrées après la dernière parenthèse, et ne ferait rien tant que vous n'avez pas tapé le point-virgule puis la touche [Entrée]. Assurez vous donc de taper l'instruction complète:
et également que vous avez un caractère 'nouvelle ligne' à la fin de la dernière ligne. De même que pour les entrées en manuel, ISQL n'exécute une ligne qu'après que vous ayez tapé [Entrée]. L'autre problème est la gestion des transactions. Si vous exécutez ISQL avec -i il quitte à la fin du fichier sans valider la transaction. Donc, si vous avez des instructions non DDL (Data Definition Language) à la fin du fichier , assurez vous d'ajouter COMMIT; derrière :
Ainsi, vous serez en mesure de voir la valeur 10 dans la table. Traduction réalisée depuis http://www.firebirdfaq.org/faq106/ |
| ||
auteur : SergioMaster | ||
- 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:
L'utilisation de FIRST dans les vues a été ajoutée à partir Firebird 2.0.1. De fait, Firebird 2 traite les vues comme des SELECTs normaux, il n'y a plus de restrictions spécifiques . Traduction réalisée depuis http://www.firebirdfaq.org/faq317/ |
| ||
auteur : SergioMaster | ||
"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/ |
| ||
auteur : SergioMaster | ||
"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:
Dans ce cas c'est la version 3.0 . Sous Windows, vérifiez simplement les fichiers DLL pour l'ICU dans le sous répertoire 'bin' de votre installation Firebird. Traduction réalisée depuis http://www.firebirdfaq.org/faq358/ |
| ||||
auteur : SergioMaster | ||||
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
Pour démarrer le serveur avec le Guardian (Guardian scrute le serveur et le redémarre en cas de crash) tapez :
Pour arrêter un serveur, tapez :
Pour forcer l'arrêt, tapez:
Si vous utilisez Firebird 2 ou une version supérieure, vous pouvez utiliser la commande 'kill' classique pour arrêter le serveur, car ce dernier traite le signal correctement. Assurez vous de d'abord arrêter ('kill') le guardian puis ensuite le serveur (sinon le guardian redémarrera le serveur). Traduction réalisée depuis http://www.firebirdfaq.org/faq256/ | ||||
lien : ![]() lien : ![]() |
Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2009 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.