Discussion :

[Y]

Bonjour,

mon fichier .gdb passe de 3800 Ko à 11000 Ko sans raison apparente,
qq insert, qq update sans erreur.
Apres un backup, la taille est corrigée et le fichier reprend ses 3800 Ko

Interbase.log : INET/inet_error: read errno = 10054

Firebird 1.0.3

qq'un aurait une idée sur l'origine de ceci ??
oubli d'une fermeture?

Merci d'avance à ceux qui ont une explication,

Yves

[Barbibulle]

Firebird ou Interbase comme beaucoup d'autre d'ailleur, utilisent la place dont ils ont besoin pour fonctionner.
Mais malgrès les deletes celle ci ne se réduit pas. Ceci est normal car optimiser la taille de du fichier de la base (le faire grossir ou diminuer) celà coute très cher en ressource. Autant grossir quand il faut il le fait il n'a pas le choix mais la réduction ca serait du luxe, d'autant qu'il utilise les éventuelles trous avant de refaire grossir le fichier.

Enfin à l'heure ou les DD sont de plus en plus gros et de moins en moins cher, on ne peut pas dire que ça soit un problème.

Pour votre cas il est possible que vos insert ou update obligent Fb à créer des versions des enregistrements en double (si les anciennes versions sont utilisés par une autre transaction par exemple). Donc explorez cette piste.
Mais bon c'est ça soupe à lui, c'est vrai que votre base étant de très petite taille, c'est facile de la doubler mais rassurez vous pour les bases normales, le fichier ne va pas doubler pour les besoins de fonctionnements interne.

[Y]

un grand merci
ca me rassure deja un peu plus, mais
y'a t-il moyen de trouver sur quel table il aurait garder un double des enregistrements? j'ai essaye gstat mais pas facile de decoder le resultat!

J'essaye en reexcutant mon code, mais l'augmentation (de 4Mo à 11Mo et 23Mo) ne semble pas se produire à chaque fois!

comment voir combien de transactions sont actives en meme temps ?!

sinon dois-je implementer un backup auto pour nettoyer le fichier gdb ??

Merci pour vos lumières !

Yves

[Barbibulle]

un grand merci
ca me rassure deja un peu plus, mais
y'a t-il moyen de trouver sur quel table il aurait garder un double des enregistrements? j'ai essaye gstat mais pas facile de decoder le resultat!

C'est sa sauce interne, on ne peux les voir directement. Ces doubles sont en fait le résultat du versionning. C'est ce qui permet notamment à FB de présenter dans une transaction snapshot toujours les même enregistrements comme s'il avait pris une photo instantannée de la base et ce même si d'autres modifie/efface ou ajoute des éléments.

J'essaye en reexcutant mon code, mais l'augmentation (de 4Mo à 11Mo et 23Mo) ne semble pas se produire à chaque fois!

comment voir combien de transactions sont actives en meme temps ?!

Ca c'est dans votre code que ca se passe. Si vous n'avez rien précisé il y a des chances que la transaction par defaut soit de type snapshot (la plus couteuse en terme de version d'enregistrement)

sinon dois-je implementer un backup auto pour nettoyer le fichier gdb ??

Oui de toute façon ca ne peux pas faire de mal.

Mais celà n'empèche qu'il faudra que vous étudiez et utilisiez correctement les transactions (sinon vous allez avoir d'autres surprises). Une fois vos transactions bien définie, je pense que votre base grossira moins.

[Y]

encore merci pour ta réponse, et ta rapidité

je retourne à mes livres,
connais tu qq adresses utiles sur le sujet ?