FAQ FirebirdConsultez toutes les FAQ

Réponse courte : Non, si vous utilisez Firebird 2

Dans les versions antérieures (1.x) la seule méthode pour arrêter correctement le Super Serveur était d'utiliser le programme fbmgr/ibmgr ainsi :

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

# killall fbserver

# killall -9 fbserver

Les commandes SHOW TABLE ou autre SHOW ... ne sont pas du SQL normalisé, ce sont des commandes de l'outil ISQL.
Si vous voulez obtenir de telles informations dans votre application, vous devrez faire une requête sur les tables systèmes (exactement ce que fait ISQL).
Vous pourrez rechercher des détails dans les codes source d'un outil d'administration tel que ISQL ou FlameRobin, ou dans des bibliothèques de connexion comme PHP de ADOdb.
Traduction réalisée depuis http://www.firebirdfaq.org/faq231/

Si vous n'obtenez aucune erreur, le problème est probablement dans la gestion des transactions.
Si vous exécutez ISQL avec l'option -i, il s'arrête à la fin du fichier sans valider les transactions. Donc, si vous avez des instructions DML à la fin du fichier, assurez vous d'ajouter un COMMIT; après

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

Vous avez probablement une colonne de type CHAR. Le type CHAR est rempli avec des espaces.

Dans l'exemple suivant :

1
2
3
4
5
6
7
CREATE TABLE testlen 
( 
c1 CHAR(5), 
v1 VARCHAR(5) 
); 
INSERT INTO testlen VALUES ('abcd', 'abcd') 
SELECT STRLEN(c1), STRLEN(v1) FROM testlen;

SELECT STRLEN(TRIM(c1)) FROM testlen;

Les tables externes utilisent encore les I/O 32 bits, donc la taille limite est de 2GB.

Si vous essayez de dépasser cette taille , vous obtiendrez une erreur de fseek, telle que ceci:

Unhandled Exception: FirebirdSql.Data.FirebirdClient.FbException: I/O error for file fseek

Ils sont crées par IBExpert pour stocker l'historique des changements dans la base de données ainsi que d'autres détails utiles.
Vous pouvez librement les détruire, bien qu'une ré-exécution de IBExpert les récréera certainement.
Il vaut mieux chercher dans les options de configuration le moyen de les désactiver.
Traduction réalisée depuis http://www.firebirdfaq.org/faq154/

Mend est utilisé pour réparer une base de données cassée pour une opération de backup. Comme elle est cassée, il y a de fortes chances que le sweep échoue - il est déjà assez que gfix ait besoin de traiter les enregistrements valides, pourquoi devrait-il s'occuper des anciennes versions?
Dans tous les cas, si vous avez une base de données corrompue et que vous utilisiez mend pour la réparer, cela n'a pas beaucoup de sens de vouloir effacer de la base cassée les vieilles versions des enregistrements. Si vous voulez vraiment le faire, essayez de faire un sweep à part.

Prenez note que mend n'est pas , normalement, nécessaire - seulement en cas de corruption de la base de données. Dans de tels cas vous devez réparer, sauvegarder et si tout va bien restaurer ce backup. Cette nouvelle base restaurée n'aura plus les vieilles versions d'enregistrement (garbage) de toute façon, donc il n'y a pas besoin de faire de nettoyage (sweep) du tout.

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

Le principal sera un moteur de gestion multithread pouvant utiliser plusieurs CPU efficacement. Les versions actuelles de Firebird ont des problèmes :

Le mode Super Serveur ne fonctionne pas sur des CPU multiples. Vous devez renseigner la variable CPUAffinity de firebird.conf pour le bloquer à un seul processeur.
C'est parfait lorsque la charge n'est pas trop importante et que votre machine serveur sert également à autre chose (serveur web par exemple), les autres applications peuvent utiliser l'autre CPU. Cependant, le SMP ne fonctionne pas.

Le mode Classic fonctionne très bien avec le SMP, mais ne s'ajuste pas très bien. Le principal problème étant les verrous entre processus utilisant des signaux.
Si vous avez un grand nombre d'utilisateurs connectés (300 par exemple) sur une machine avec 4 CPU, cela signifierait que les 300 processus ont besoin d'obtenir des informations de verrouillage de ces 4 processus (1 par CPU) utilisant la base de données.
Cet encombrement d'informations crée beaucoup de trafic et de charge. Un moteur multithread correct pouvant travailler sur plusieurs CPU corrigera cela, car les communications seront faites à l'intérieur d'un seul processus sans blocage des facilités du système d'opération.

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

Si vous avez la curiosité de demander les statistiques d'une base de données Firebird vous verrez affichée, entre autres, la valeur 'Bumped transaction 1'.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# gstat ?h c:\chemin\base.fdb 
 
Database "c:\chemin\base.fdb" 
Database header page information: 
Flags0 
Checksum12345 
Generation1114 
Page size1024 
ODS version10.1 
Oldest transaction1101 
Oldest active1102 
Oldest snapshot1102 
Next transaction1103 
Bumped transaction1 
Sequence number0 
Next attachment ID54 
Implementation ID16 
Shadow count0 
Page buffers0 
Next header page0 
Database dialect3 
Creation dateNov 25, 2008 13:30:42 
Attributesforce write 
 
    Variable header data: 
Sweep interval:20000 
*END*

Le mode Classic du serveur Firebird s'exécute via xinetd ou inetd qui ont leurs propres configurations et contrôles d'accès.

si vous utilisez Inetd, vérifiez le fichier /etc/inetd.conf et retrouvez la ligne démarrant le serveur Firebird (généralement celle commençant par gds_db). La valeur de la 4éme colonne de cette ligne est quelque chose comme 'wait.30000', où 30000 sera le nombre d'instances du serveur Firebird pouvant être démarrées dans un intervalle de 60 secondes.

Si vous utilisez Xinetd, les valeurs par défaut sont dans le fichier /etc/xinetd.conf, et les valeurs 'par service' situées dans le fichier /etc/xinetd.d/firebird écrasent les valeurs par défaut, si présentes. Vérifiez la variable 'instances' dans ces deux fichiers car elles déterminent le nombre total d'instances du serveur pouvant s'exécuter de manière simultanée. Ces valeurs sont utilisées pour contrôler le chargement du serveur.
Traduction réalisée depuis http://www.firebirdfaq.org/faq161/

Si vous recherchez une sorte de constructeur de requête à donner à vos utilisateurs, il existe un freeware de Fast Reports Inc.

http://fast-report.com/en/products/f...y-builder.html

Il peut être utilisé avec Delphi et Borland C++ Builder
Traduction réalisée depuis http://www.firebirdfaq.org/faq190/

Oui. Tous les objets d'une base sont stockés dans les tables systèmes (nom commençant par RDB$) et la plupart de ces tables ont une colonne RDB$DESCRIPTION, qui est un champ BLOB texte lisible, dans lequel vous pouvez mettre du texte.

La plupart des outils d'administration graphiques vous donne un moyen facile pour modifier directement ces descriptions
(par exemple, chaque page de propriétés de FlameRobin montre ces descriptions par défaut).
Il existe également un outil gratuit spécialisé nommé IBDesc qui est également capable d'imprimer de bons états sur la base de données entière: tables avec ses colonnes et descriptions.
Traduction réalisée depuis http://www.firebirdfaq.org/faq296/

Pas directement dans le moteur, mais il existe des solutions tierces :

http://www.ibobjects.com/ibofts.html
http://www.textolution.com/ftsib.asp
http://www.codeproject.com/cs/databa...xtFirebird.asp
http://www.tamaracka.com/
http://sourceforge.net/projects/mutis
http://www.sphinxsearch.com/

Il existe une fourche du code Firebird fait par la compagnie Red Soft. Elle a la même licence que Firebird, vous pouvez donc y jeter un ?il , leur version permet la recherche de texte en utilisant le moteur Lucene via les interfaces JavaVM http://www.red-soft.biz/en/index.html

Vous pouvez également lire l'article "Full text search in Firebird without a full text search engine" de Bjoern Reimer and Dirk Baumeister, présenté lors de la 4éme Conférence Firebird :
http://www.ibphoenix.com/downloads/F...H-TPZ303-R.zip
(exemples et sources inclus)

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

Oui.

Quelques remarques importantes cependant :

a) Utilisez 'écriture forcées' (forced writes). Le cache du système de fichiers pour les périphériques USB a une latence plus importante que les disques durs normaux, il est donc très facile de perdre un nombre conséquent de données en cas de coupure d'alimentation.

b) Assurez vous que les utilisateurs soient conscients des conséquences d'une extraction de clé alors que votre application est toujours en cours.

c) Prenez note que les disques USB sont prévus pour environ un million de cycles effacement/écriture. Quand l'écriture forcée est active, chaque instruction et transaction fait une écriture disque, donc vos utilisateurs peuvent facilement faire de 100 à 1000 réécritures par jour - ce qui veut dire le temps de vie de votre disque USB risque d'être réduit.

d) Il est recommandé que vous fassiez, si possible, une copie de votre base de données sur le disque dur, ou pour le moins forcez vos utilisateurs à faire des backups régulièrement.

La meilleure pratique reste de faire une copie de la base sur le disque dur - travailler avec - puis ensuite de la réécrire sur le disque USB.

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