Précédent   Forum des professionnels en informatique > Bases de données > Firebird > Connexion aux bases de données
Connexion aux bases de données Forum d'entraide sur la connectivité Firebird: composants, drivers, transactions, etc.
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 25/04/2007, 08h57   #1
Invité régulier
 
Inscription : mai 2004
Messages : 26
Détails du profil
Informations forums :
Inscription : mai 2004
Messages : 26
Points : 7
Points : 7
Par défaut [Delphi - Firebird] Comment faire bon usage des transactions?

Bonjour,

N'ayant pas trouvé d'exemples assez détaillés sur le net, je me permets de faire à nouveau appel à vous pour obtenir de plus amples renseignements sur la gestion des transactions sous Firebird !

L'appli que je suis en train de développer étant destinée à être multi-utilisateur, me voilà plongée en plein dans le monde des transactions !

En parcourant le forum et la faq, j'ai pu comprendre que la bonne vieille méthode : un composant TIBDataBase, un composant TIBTransaction et tous les DataSet connectés à la même transaction était loin de permettre de tirer profit au maximum de Firebird !

Ainsi je me permets de poster ici la méthode que j'emploies actuellement afin que vous puissiez me donner vos avis éclairés...

Exemple :
Une première fenêtre présente une DbGrid contenant la liste des clients. Sur l'évènement FormShow, j'exécute le code suivant :
Code :
1
2
 DMPrincipal.IBTransaction.StartTransaction;
   DMprincipal.IBDataSetCLIENTS.Open;
Sur l'événement OnClick du DbGrid, j'ouvre une autre fenêtre contenant la "fiche" du client sélectionné, on associe à cet événement le code suivant :
Code :
1
2
3
4
5
6
7
8
9
10
 
  DMprincipal.IBTransaction.Commit;
  DMprincipal.IBTransaction.StartTransaction;
 
  DMprincipal.IBDataSetClient.ParamByName('numclient').AsInteger := NumClient;
 
  DMPrincipal.IBDataSetClient.Open;
 
  FClient.NumClient := NumClient;
  FClient.ShowModal;
Ensuite lors de la fermeture de la fiche client, la transaction est à nouveau fermée, puis rouverte afin de "recharger" le DBgrid.

Voilà, je souhaiterai savoir ce que vous pensez de cette manière de fonctionner?
De plus, si vous avez des exemples de code utilisant les transactions, n'hésitez pas!

Merci d'avance pour votre aide..
Lili21 est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 30/04/2007, 10h47   #2
Membre Expert
 
Avatar de Barbibulle
 
Frédéric
Inscription : octobre 2002
Messages : 1 722
Détails du profil
Informations personnelles :
Nom : Frédéric
Âge : 42

Informations forums :
Inscription : octobre 2002
Messages : 1 722
Points : 2 025
Points : 2 025
Citation:
Envoyé par Lili21
Une première fenêtre présente une DbGrid contenant la liste des clients. Sur l'évènement FormShow, j'exécute le code suivant :
Code :
1
2
 DMPrincipal.IBTransaction.StartTransaction;
   DMprincipal.IBDataSetCLIENTS.Open;
La première ligne est inutile puisque l'ouverture du Dataset va démarrer la transaction (si celle ci ne l'était pas déjà).


Citation:
Envoyé par Lili21
Sur l'événement OnClick du DbGrid, j'ouvre une autre fenêtre contenant la "fiche" du client sélectionné, on associe à cet événement le code suivant :
Code :
1
2
3
4
5
6
7
 
  DMprincipal.IBTransaction.Commit;
  DMprincipal.IBTransaction.StartTransaction;
  DMprincipal.IBDataSetClient.ParamByName('numclient').AsInteger := NumClient;
  DMPrincipal.IBDataSetClient.Open;
  FClient.NumClient := NumClient;
  FClient.ShowModal;
Ensuite lors de la fermeture de la fiche client, la transaction est à nouveau fermée, puis rouverte afin de "recharger" le DBgrid.
Voilà, je souhaiterai savoir ce que vous pensez de cette manière de fonctionner?
J'en conclus que vous utilisez le meme composant transactionnel pour votre grille et votre fiche de mise à jour. Dans ce cas vous n'avez aucun interret à fermer la transaction (en faisant un commit puis de l'ouvrir avec un start) juste avant l'ouverture de votre fiche client. Celà génère du trafic inutile.

Enfin lorqu'on parle de transaction il faut préciser comment est paramétrée votre transaction sinon nous parlons un peu pour rien.
Snapshot, read committed, read only table stability, ...

Si vous n'avez pas configurez le composant transaction il est en mode Snapshot. Dans ce mode vous ne voyez pas les modifications que les autres transactions (de la meme application ou des autres postes) valident. Une fois ouverte, c'est comme si elle prennait une photo de votre base de données.

En mode read commited vous allez pouvoir voir les modifications validées apportées par les autres. De plus cette transaction sera moins lourde à maintenir pour le serveur.

Idéalement il faut que la transaction soit de niveau le plus bas possible et la plus courte possible (Le cas idéal étant de ne rien ouvrir et de ne rien toucher ). Dans la pratique (il faut bien travailler ) je vous conseille d'utiliser par défaut le mode read commited (qui est le mode le plus facile à comprendre, car assez 'naturel') avant de vous lancer dans les autres modes. Et d'utiliser plusieures composants transactionnels. Un pour vos grilles (dans cette transaction nous ne faites pas de mise à jour de données, que des lectures) et un autre pour vos mise à jours (cette dernière sera fermée dès que possible par un commit ou rollback).

Voilà de quoi commencer à vous exercer.
Barbibulle est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 07/05/2007, 20h59   #3
Membre Expert
 
Avatar de edam
 
Inscription : décembre 2003
Messages : 1 716
Détails du profil
Informations forums :
Inscription : décembre 2003
Messages : 1 716
Points : 1 783
Points : 1 783
Citation:
Envoyé par Barbibulle
Dans la pratique (il faut bien travailler ) je vous conseille d'utiliser par défaut le mode read commited (qui est le mode le plus facile à comprendre, car assez 'naturel') avant de vous lancer dans les autres modes. Et d'utiliser plusieures composants transactionnels. Un pour vos grilles (dans cette transaction nous ne faites pas de mise à jour de données, que des lectures) et un autre pour vos mise à jours (cette dernière sera fermée dès que possible par un commit ou rollback).

Voilà de quoi commencer à vous exercer.
tu peut expliqué plus, j'ai déjà lu que snapshot est le meilleur, et là tu met tout mes idée en gris
en plus, j'ai jamai éssye d'utlisé plus d'un composant TIBTransact, en peut le faire? et que raport tt sa pour mon aplis,
autre chose, tt est transactionnel, même select?? sa veut dire que je dois commité aprés chaque select?? pas vraie non ?
__________________
PAS DE DESTIN, C'EST CE QUE NOUS FAISONS
edam est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 16h07.


 
 
 
 
Partenaires

Hébergement Web