Version imprimable
Vous ne devriez même pas vous trouver dans ce mode d'isolation... Vous risquez de vous générer des problèmes par la suite.
Une question : Etes vous obligé à chaque fois de remonter l'ensemble des données de votre table ? Au fur et à mesure que votre application va ajouter des données dans votre table vos temps de récupération de données vont augmenter.
Ne pouvez pas réaliser une restriction dans votre select ?
++
Je remonte tot les enregistrement en meme temps, car je veux afficher chaque enregistrment correspondant a ma requete, dans une list box.
Mais je réfléchit a faire une boucle sur un select avec un seul element renvoyer, jusqu'a ce qu'il n'y ai plus d'élement ds ma base correspondant a ma requete..
Mais comment connaitre le nombre d'élément correpondant dans ma base, a une requete, si je ne recupere pas d'abord totu ses enregistrement...
Et puis, comment ne pas recupere tjr le meme element dans la boucle , soit comment deplacer un genre de curseur dans ma base, que ferai la nouvelle recherche correspondante a chaque nouvelle boucle, en 'zappant l'élément prédemment renvoyé.. ?
Je manque de cours SQL, mais voila ma problématique d'aujourd'hui....
Bonne nouvelle, je vien d'essayer avec le mode REPEATABLE READ, et cela fonctionne aussi.Apres avoir lu des doc sur ce mode, j'ai vu qu'il autorisai aussi la lecture et l'écriture simultanément sur la même table, en ayant toute la table dans une select :P.
Ce mode est -il beaucoup plus sur ?
Avez vous des doc comparatif qui explique les avantages et inconvénient de tous ces mode ?
J'ai deja de quoi faire avec le lien sur Developpez.com, mais toute info supplémentaire est bien venu.
En tout cas, merci beaucoup.
Autant pour moi....
Erreur de manip, Le READ UNCOMMITTED est bien el seul mode qui ne me fait pas pédaler SQL...
mais merci quand meme de vos réponse, cela m'a était indispensable.
Je vais maintenant cherché si il est possible de déverrouiller un enregistrement...
Merci beaucoup.