Discussion :

[didinside]

Bonjour,

Mon problème est le suivant, je cherche comment gérer la gestion des accès a mes données par plusieurs clients en même temps.

Je m'explique, j'ai un DB firebird 1.5 qui tourne sur un serveur ainsi qu'un programme client (développé en delphi 6 pro) qui tourne sur plusieurs autres PC. Ce programme est une gestion après-vente avec gestion des clients, des articles, etc...

Si un PC client accède à la db, aucun prob, tout marche nickel.
Si 2 PC client accède à la db, tout fonctionne très bien TANT que les 2 ne modifient pas le MEME enregistrement en même temps.
S'ils rentrent tous les 2 en modification sur l'enregistrement article X (par exemple), les données seront mise a jour par celui qui sauvera en dernier.

J'aimerais trouver un moyen de dire au PC client (X) que l'enregistrement qu'il voudrait modifier EST DEJA en cours de modification par un autre PC client (Y).

Y-a-t-il moyen de faire ça au niveau des transactions ?

J'ai bien pensé a une solution, mais je ne la trouve pas très élégante.
En effet, la seule chose que j'ai trouvé jusqu'a présent est de créer un table dans ma db dans laquelle chaque client ira "dire" qu'il est en train de modifier tel champs. Ainsi quand un client veut modifier un champ, il va d'abord consulter cette table spéciale et renvoi un message si l'enregistrement est déjà en cours de modif par un autre client...
Bien sur dans le cas ou l'application qui a "vérouillé" un enregistrement PLANTE, l'enregistrement reste "vérouillé" et on doit le dévérouiller soit même.... pas très élégant tout ça.

Donc je recherche activement une autre solution...
Dernière chose, je suis en 2 tiers (DB + Client)

Merci pour ceux qui m'auront lu jusqu'au bout.

[Barbibulle]

Quel FAI utilisez vous ?
IBX ?

Comment avez vous configuré vos transactions ?
Utilisez vous la même transaction pour mettre à jour et pour l'affichage des données ?

[didinside]

FAI, il n'y en a pas, tout est en réseau local

Oui j'utilises les composants IBX.
Les transactions sont configurées en Read Commited

En fuinant un peu sur le forum, j'ai retrouvé ce message ci qui se rapproche très très fort de mon problème.
http://<br /> http://www.developpez...nsaction<br />

Ce que j'aimerais, c'est éviter que 2 personnes ne modifent le même enregistrement en même temps pour la simple et bonne raison que l'update est fait par un TIBSql (très rapide et très bref)

Pour résumé, chaque programme client fonctionne de cette manière la :
- un dbgrid affiche le contenu partiel d'un table (en fonction des critères de recherche de l'utilisateur), avec un TIBDataset
- si l'utilisateur veut modifier l'enregistrement, il click sur un bouton et un autre formulaire s'affiche avec les infos de l'enregistrement (que j'ai repris de la dbgrid)...
- l'utilisateur change les données qu'il veut et click sur sauvegarder. La j'applique les changements (update) via un tibsql.

Ce qui fait que si plusieurs utilisateurs "rentre" en modification du même enregistrement, ils vont appliquer chacun a leur tour les modifications et ce sera le dernier qui aura gain de cause... voila pq lorsque je rentre dans mon formulaire de mofication, j'aimerais avertir l'utilisateur que qqun est déjà dessus.

Et j'ai 2 transactions, une pour l'affichage avec le TIBDataset et une pour la mise a jour avec le TIBSql[/url]

[Barbibulle]

C'est bien ce que je pensai.

Le problème c'est qu'interbase fonctionne comme vous avez pu le lire dans le message que vous avez trouvé en mode en multiversionning et non en mode verrou.

Le tres gros avantage de ce mode de fonctionnement c'est que notamment c'est beaucoup plus léger en maintenance (on n'est pas obligé d'avoir un DBA chez le client qui va déverrouiller les enregistrements qui seraient restés verouillés suite à un plantage par exemple.).

Donc à moins que vous ayez Firebird1.5 (qui permet le verouillage je crois) vous ne pourrez pas avertir un utilisateur qu'un autre est en train ou va modifier l'enregistrement en cours. Par contre vous pouvez faire en sorte qu'il soit prévenu lors qu'il essayera à son tour de mettre à jour le même enregistrement. Et lui dire que quelqu'un d'autre l'a modifié entre temps. (C'est le comportement par défaut si vous n'utilisiez que le composant TIBDataSet pour la lecture mais aussi pour les mises à jours).
Dans votre cas pour avoir ce comportement sans trop modifier votre code, attribuez au TIBSQL la même transaction que le TIBDataSet.

Car voilà ce qui se passe actuellement :
La transaction T1 est ouverte en mode readCommited et le IBDataSet lit les données de DUPOND.
Une seconde personne fait de même et modifie DUPOND et Commit la modification qui devient donc DUPOND version2.
Comme le premier poste ne fait pas de refresh il ne voit pas la modif. Modifie à son tour DUPOND et comme vous ouvrez une autre transaction pour la mise à jour c'est bien DUPOND version 2 qui est visible donc l'Update est appliqué.

si vous etiez dans la même transaction :
La transaction T1 est ouverte en mode readCommited et le IBDataSet lit les données de DUPOND.
Une seconde personne fait de même et modifie DUPOND et Commit la modification qui devient donc DUPOND version2.
Comme le premier poste ne fait pas de refresh il ne voit pas la modif. Modifie à son tour DUPOND lors de l'update, il s'apperçoit que l'enregistrement DUPOND (version1) n'existe plus et à été remplacé par un DUPOND (version2) Une erreur est générée, la mise à jour n'est pas appliquée.

Je ne sais pas si j'ai été tres clair...
Pour résumer : Soit vous utilisez également le TIBDataSet pour vos mises à jours (et donc dans la même transaction) et avant d'afficher l'écran de modification d'un enregistrement vous demandez la dernière version validée en faisant un IBDataSet.Refresh.
Soit vous ne voulez pas modifier beaucoup votre code et donc vous reliez votre TIBSQL à la même transaction que le TIBDataSet. (Et vous faites un refresh avant d'afficher l'écran de modif de l'enregistrement).

Voilà

[didinside]

Merci pour la réponse...effectivement vous avez bien compris mon problème.
De mon coté, je pense avoir bien compris le "multiversionning"...

Ce qui m'embète la-dedans, c'est que l'utilisateur va passer de temps a encoder des modifications avant de se rendre compte que l'enregistrement a déjà été modifié... et ce cas de figure apparaitra souvent car 2 des services (client et technique) iront voir et surtout mofidier les mêmes enregistrements... d'ou ma tentative de trouver une gestion des accès aux modifications des données.

Effectivement, je viens de voir que firebird permet de faire un lock sur un enregistrement (voir plusieurs), mais ils le déconseillent assez fortement.
Comme j'ai firebird 1.5, je vais quand même tenter d'essayer ...

[Barbibulle]

Ce qui m'embète la-dedans, c'est que l'utilisateur va passer de temps a encoder des modifications avant de se rendre compte que l'enregistrement a déjà été modifié... et ce cas de figure apparaitra souvent car 2 des services (client et technique) iront voir et surtout mofidier les mêmes enregistrements... d'ou ma tentative de trouver une gestion des accès aux modifications des données.

Dans le cas du verroux, le probleme est que si ca plante il va falloir deverouiller manuellement...
De plus vous allez être confronté à un autre probleme : L'enregistrement est verouillé par un autre utilisateur, donc je ne peux pas le modifier... j'attend... j'attend..... j'attend, je dois absolument le modifier.... j'addend encore, (c'est long... Il en met du temps à le modifier) ah ! enfin je peux le modifier.
Si vous voyez ce que je veux dire...Sans compter ceux qui carrement vous appeleront pour deverouiller l'enregistrement croyant que c'est un verroux resté accidentellement...

Moi je fais en sorte que soit les personnes ne travaillent pas sur les meme choses oubien me débrouille pour que la phase de modification soit la plus courte possible.
Debut transaction read commited,
affichage de l'enregistrement
Passage en mode Edit : refresh (chargement de la dernière version connu de l'enregistrement)
L'utilisateur modifie.
Update et Commit des modifs.

Ainsi la phase de modification est très courte.
Si jamais il y a un message disant que l'enregistrement a été modifié, vous pouvez afficher les différences. et demander à l'utilisateur si on met à jour ou non.

[didinside]

Effectivement, c'est une façon de faire et cela nécessitera des modifications dans mon code, mais au moins dans ce cas, je n'aurais jamais le problème des verrous qui sont perdus.

En tout cas, un grand merci pour tes réflexions et tes pistes Barbibulle.

PS : si jamais j'arrive à trouver une gestion via les verrous proposé dans firebird 1.5 (WITH LOCK), je n'hésiterai pas à vous tenir au courant.

[Barbibulle]

PS : si jamais j'arrive à trouver une gestion via les verrous proposé dans firebird 1.5 (WITH LOCK), je n'hésiterai pas à vous tenir au courant.

Merci ça peux être interressant d'avoir un retour sur ce mode de fonctionnement.

[didinside]

Voila, j'ai passé ma soirée a fuiner un peu partout et j'ai trouvé une solution a mon problème avec la nouvelle méthode WITH LOCK implémentée dans Firebird 1.5.

En gros voici un bout de code pour la détection/mise sous verrou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
      // on fait un select de l'enregistrement que l'on désire modifier en mettant la clause WITH LOCK 
      DM.IBTR_CLI2.Active:=True;
      DM.IBSQL_CLI2.Close;
      DM.IBSQL_CLI2.SQL.Clear;
      DM.IBSQL_CLI2.SQL.Text := 'SELECT CODE_CLI FROM CLIENT WHERE CODE_CLI='+QuotedStr(Ed_codecli.Text)+' WITH LOCK';
      try
        DM.IBSQL_CLI2.ExecQuery;
        // si aucune exception n'est levée, l'enregistrement sélectionner est vérouillé en écriture.  Vous serez donc le seul a pouvoir le mettre a jour. Ne pas oublier de fermer la transaction, car tant que vous n'aurez pas fait un commit ou un rollback, le verrou reste d'actualité.
      except
        on E: EDatabaseError do
            Showmessage('ATTENTION, quelqu''un est en train de modifier l''enregistrement. Veuillez réessayer plus tard');
        //Si l'enregistrement est déjà vérouillé par qqun d'autre, il vous est toujours possible de faire un simple select et d'afficher le contenu du champ vérouillé. 
      end;

Cela fonctionne plutôt bien et si l'application qui verouille un champ "plante", celui ci est automatiquement déverouillé. Du moins avec les quelques tests que j'ai fais, cela s'est passé comme ça.

La méthode proposée par Barbidulle était interessante, mais vous ne vous aperceviez que l'enregistrement avait DEJA été changé que lorsque vous essayiez à votre tour de le mettre a jour.

Pour conclure, a toute fin une méthode...et dans mon cas, celle-ci me convient à merveille.

Sur ce, bon codage et bonne .... nuit :p.

PS : si vous voulez + d'info, voici quelques liens :
http://www.destructor.de/firebird/1....icit_locks.txt
http://www.interbase-world.com/en/articles/805.php

[Barbibulle]

Merci du retour d'info