Bon voila
je suis sure une aplication de gestion de maintenance , je travail avec Delphi  et MySQL 5 j'utilise ADO et une conexion ODBC a ma BDD,g un probleme concernant la gestion de la concurance d'acces a ma BDD .g rencontrer ce probleme dans le contexte suivant :
Modification d'un contrat :
un contrat de maintenance englob des materielles .
 01- l'orsque un utilisateure charge un contrat pour modification j'execute une requette qui renvois les equipement couverts pas ce contrat , afin que l'utilisateure puisse modifier (ajouter ou suprimer un ou des equipements) ce contrat
02- je transfert la contenue de la requette vers un ListeVieuw
03- l'utilisateure peut suprimer une ligne (un equipement) ou en ajouter une autre, cette etape peut prendre su temps selon le nombre d'equipement a ajouter ou suprimer et selon l'utilisateure.
04- il enregistre les modifications en appuiyant sur le bouton enregistrer.
05- je transfert le contenue du ListeView vers les tables concernées en efectuant les modifications necessaires (ajout ou supression des equipements)
le probleme c'est que entre l'etape 1 et 4 un autre utilisateure peut fait le meme traitement en entier pour le meme contrat et la c la cata.
- je ce pas si les transactions peuvent m'aider a gerer ce probleme
- ou bien il faut passer par le verouillage des tables ou des enregistrement utilisés par cette procedure
dans les deux cas g jmais utiliser ni les transactions , ni le verouillage , g pas trouver un bon tutorial , merci d bien vouloire m'eclaircire les idées cars c la premier fois pour moi que je travail sur une BDD reseau ,
pour l'instant la seule solution que g trouver pour contourner ce probleme c créer un champ boolean sur toutes mes tables , et vant chaque ouverture de contrat je le mét a 1 pour chaque enregistrement , et a la fin de modification je le remét a 0 , et avant chaque acces je verifie si les enregistrement que je v chargé sont a 1 (verouillé par un autre utilisateure) ou a 0(non verouillés), je simule un verouillage d'enregistrement , je c que c pas une solution tres elegante , cars je suis sure qu'il existe quelque chose dans le SGBD qui gere ca, merci
*apartir de MySQL 5 on a une gestion de transactions et des procedures stockées.

Oh la la la : arrettee le style SMS. On a une langue magnifique : respectons là.

il faut d'abord définir ce que tu veux (accès partagé, accès concurrentiel etc..) et ensuite tu chercheras ce dont tu as besoin..

je m'excuse pour le langage sms aforce je me rend pas compte , et le pire c'est qu'il m'arrive de parler en sms meme sur la feuille d'examain alors je vous lesse imaginer la reaction des profs :-(

pour mon aplication elle doit pouvoir etre utilisé par plusieurs utilisateurs en meme temps , ya plusieurs fonctionalitées qui ne sont pas forcement conflictuelles entres elle mais celle de modification generalement elle le sont comme le cas expliqué ci desus
alors je c pas moi mais je pense que c un aces partagé qui doit gerner la concurance d'aces  dans certains cas seulement pas tout pour tout les accés .
a vous de me suggerer une solution adéquate a mon probleme . merci

Les transactions servent justement à éviter ce genre de probleme

Tout ce passe ici

merci mais j'avais deja consulter cete article sure developpez.com , concernant l'expliquation donée pour ADO je trouve que c un peut trop juste pour comprendre un concepte des plus délicat concernant l'integrité de la BDD.j'ai consulter la docuentation de ADO , la documentation de MySQL 5 et je trouve toujours juste ne bréve discription ;(
je me demmande encore quelle niveau d'isolation je doit choisir pour mon cas,si j peut declancher une transaction sur une forme et la valider ou l'annuler un peut plus loin sur une autre forme, ce que veut dire exactement un Trehad ,esque c'est une conexion d'un utilisateure ou bien un dataset sur le meme utilisateure ,je trouve que c trop complex pour qu'on puisse comprendre coment s'en servir apartire d'un petit exemple, c pour ca que je m'adresse a vous en esperant que quelqu'un puise m'eclerer .merci.

je confirme Francky23012301, transaction : StartTransaction, commit, Rollback bon courage