Version imprimable
bonsoir a tous ,
j'utilise interbase 7.5 server sous delphi 7 , et c'est avec les composants IBX que je fait la connexion avec ma base .
j'ai un souci de verrouillé un enregistrement .
j'ai vu cette question
http://www.developpez.net/forums/d11...nregistrement/
mais sa me plait pas.
SVP , réellement comment vous faite pour ce genre de problème.
bon courage a tous.;)
Bonjour,
La méthode que tu as lu ne te convient pas, mais elle me paraît correcte et présente une solution à ton problème. Après, il serait intéressant de savoir ce qui te gêne.
Autre approche, il est possible de créer une table affectée au verrouillage des enregistrement de la table en cours d'utilisation pour l'opération, il ne s'agit que d'une variante de la solution précédente. Avant l'utilisation de l'enregistrement, tu l'inclus dans la table verrouillage et le supprime dès que l'enregistrement devient libre. Si un autre opérateur veut l'utiliser l'enregistrement, il est impératif de vérifier qu'il ne soit pas déjà verrouillé.
Après, il faut peut-être examiner la méthode de programmation pour éviter de faire gérer, par l'application, le verrouillage des enregistrements. Il convient simplement de traiter par transaction les modifications de la base. Pour cela, il a lieu de mettre en place un accès en lecture uniquement pour afficher les éléments de la table.
Pour l'insert, l'update ou le delete, il faut mettre un deuxième accès qui fera ces opérations dans une transaction. Immédiatement, après le commit, il convient de rafraîchir les affichages pour prendre en compte les modifications.
Dans cette approche, il préférable d'éviter les composants DB... et de traiter par code les actions à faire.
Cette approche fonctionne parfaitement sans aucun conflit, car c'est toujours le dernier commit qui sera visible dans la base.
Bonjour,Et vous avez entièrement raison ! :bravo:Citation:
Envoyé par aimer_Delphi
C'est du bricolage qui témoigne d'une méconnaissance profonde du fonctionnement d'Interbase et des autres SGBDR en général !
En premier lieu, je pourrais dire RTFM ! ou LCPM pour les francophones (Lisez Ce P... de Manuel) ! ;)Citation:
Envoyé par aimer_Delphi
Les SGBDR dignes de ce nom disposent du mécanisme des transactions et du niveau d'isolation de celles-ci par rapport à leur environnement.
Avec ces possibilités, on peut ou plutôt on doit gérer les problématiques de mise à jour des données (dont leur verrouillage).
Des composants IBX, un en particulier va nous aider à traiter ce problème : TIBTransaction et sa propriété Params dans laquelle on va insérer différents mot-clés :
- Le niveau d'isolation des transactions
- read_committed : permet de voir les donnés validés (committées) par les autres transactions, voire de les modifier.
- concurrency (~ snapshot) : La transaction travaille sur un instantané de l'ensemble de la base de données, sans voir les données mises à jour ultérieurement par les autres transactions.
- consistency (~ snapshot table stability) : comme précédemment, si ce n'est que la transaction verrouille en écriture les lignes qu'elle lit. Les autres transactions peuvent lire ces données.
- Le mode d'accès
- read : La transaction ne peut que lire des données dans la base.
- write : La transaction peut lire et écrire des données dans la base.
- La gestion des verrous si rencontrés
- wait : Si une ligne est verrouillée, la transaction attendra que la ligne soit déverrouillée .
- nowait : Si une ligne est verrouillée, la transaction renverra une erreur.
- La réservation des tables
- shared
lock_write=NomDeTable :Toute transaction en écriture avec le niveau d'isolation concurrency ou read_committed peut mettre à jour la table. Toutes les transactions peuvent lire la table.- shared
lock_read=NomDeTable : Toute transaction en écriture peut mettre à jour la table. Toutes les transactions peuvent lire la table.- protected
lock_write=NomDeTable : Aucune autre transaction ne peut mettre à jour la table. Les transactions avec le niveau d'isolation Concurrency et read committed peuvent lire la table.- protected
lock_read=NomDeTable : Aucune autre transaction ne peut mettre à jour la table. Toutes les transactions peuvent lire la table.
En mixant ces paramètres, vous devriez trouver la solution à vos problèmes.
N'oubliez pas que plus vous mettrez de contraintes élevées sur vos transactions (donc des limites sur les accès concurrents), plus courtes devront être vos transactions...