Discussion :

[lio33]

Bonjour.

Trois points sur lesquels je souhaiterai avoir des précisions :

1) Backup et Restore
Il est recommandé d'effectuer des Restauration d'une base de données pour forcer le moteur FB ou IB à reconstruire Index, etc.
Généralement lorsque l'on effectue une restauration, est-elle effectuée vers le fichier BDD origine ou vers un nouveau fichier ?

2) Transactions :
Je viens de lire sur ce forum un message concernant les transactions et le risque de voir des transactions non refermées suite à des problèmes de postes clients. Je suis dans cette configuration, une dizaine de postes clients avec une application spécifique et une serveur de base de données Interbase 7.5 . Evidement il n'est pas exclu qu'un plantage de poste client puisse survenir durant la réalisation d'un accés à la BDD. J'utilise presque exclusivement des procédures stockées. leur appel est encadré dans mon appli dans des transactions.

Est-il possible de savoir facilement si des transactions sont non terminées au niveau du serveur ?

Je suppose que le schéma application cliente qui accède directement à une BDD est courant. Quelles sont les autres solutions pour s'affranchir de ce problème de transaction ouverte?

3) Versionning données :
De même on parle de versionning des données.
Les différentes modifications d'une même informations sont conservées dans IB ?
Est-ce paramétrable ?
Comment ne conserver que la dernière modification ? En commitant ?
Comment déterminer sur le serveur IB les informations dont on conserve plusieurs versions ?

D'avance merci pour vos infos.

[jean-jacques varvenne]

pour le backup restore, bien sûr qu'il faut remplacer le fichier d'origine, mais cela peut ce faire en plusieurs temps:
1) restauration avec un nom temporaire
2) arrêt de la base de données
3) destruction du fichier de la base de données (venant d'être arrêtée)
4) renomer le fichier temporaire en nom de la base de données
5) remettre en ligne.

Pour les transactions, une rupture de connexion quelqu'en soit l'origine produit l'abandon de la transaction en question. les données n'étant pas commités ne seront donc pas visible.

il faut savoir que la perte de transactions fini par ralentir la base de données.


pour le versionning? à ma connaissance, il n'est pas possible via une requête de récupérer les versions d'une même données.
Une solution est de créer soit plusieurs champs qui contiennent les données à différentes versions, soit un champ de type "array", ce qui revient au même.
Et les différentes modifications sont effectivement conservée (transaction) jusqu'au moment d'un commit ou d'un rollback. c'est d'ailleurs la raison pour laquelle la base ralentie au fur et à mesure que le nombre de transactions ouvertes s'accumules.

il y a plusieurs posts à ce sujet et des tutos sur ce forums.