Discussion :

[NicoDD.]

Bonjour,
Après quelques recherches dans la FAQ et le forum, je ne trouve pas spécialement de réponse à ma question.
Tout d'abord Je ne suis pas un grand spécialiste de SQL, mais j'essaie de m'adapter.

Les faits :
Pour l'instant c'est l'étude rien a été fait.
Je vais avoir besoin dans une base (à ma disposition SQL SERVER 7 ou 2000) d'afficher chaque enregistrement d'une table et d'enregistrer les modifications. Tous les enregistrements vont devoir être traités.
Plusieurs utilisateurs (une petite dizaine) vont avoir chaque enregistrement remonter automatiquement (php ou asp)
J'envisageais de mettre un statut sur chaque enregistrement (du style a traiter,traité) mais comment s'assurer que 1 utilisateur n'aura pas le même enregistrement qu'un autre.
Je pensais tout d'abord lors du SELECT (sur le 1er élément "à traiter" faire un UPDATE pour passer son statut "en cours") mais j'ai peur que le temps de faire la modification sur le statut "en cours", ce même enregistrement remonte pour 1 autre utilisateur.

Ne sachant comment aborder ce problème de façon sécurisé je me tourne vers vous afin de m'orienter.

Merci par avance.

NicoDD.

[Népomucène]

Lors d'une "demande pour un enregistrement" de l'application,
tu peux envoyer à SQL Server le nom d'utilisateur (qu'on suppose unique !) de l'application.
En plus d'une colonne "statut", tu peux ajouter une colonne "Attribution" et y placer le nom de l'utilisateur ayant "réclamé" un enregistrement.
récupération :

Code :

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

SELECT * FROM maTable WHERE Status = 'en cours' AND Attribution = 'Wladimir'

Cela permettra de savoir aussi qui a fait quoi comme traitement.

[NicoDD.]

Merci pour ta réponse....
Donc si j'ai bien compris :

1: je fait un SELECT sur le premier enregistrement disponible (statut en cours) puis fait un UPDATE de attribution (qui sera sans données au départ) avec pour données le nom unique de l'utilisateur.

2. je récupère cet enregistrement et l'affiche à l'utilisateur concerné.

Si échec en 2. car un autre utilisateur a fait une demande attribution en même temps sur le même enregistrement je recommence 1.

Ai-je bien tout compris ?

Merci.

[Népomucène]

Il n'y aura pas d'échec ...

Il faut utiliser la baguette magique de la transaction

[NicoDD.]

Il n'y aura pas d'échec ...

Il faut utiliser la baguette magique de la transaction

J'ai peur de ne pas être le Harry Potter de la Transaction....

Si tu peux m'éclairer.....


Merci.

Nico

[Népomucène]

C'est probablement encore plus simple.
On suppose que chaque enregistrement est numéroté par un compteur (clé primaire recommandée).
Donc une application cliente va envoyer directement la requête suivante :

Code :

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

1
2
3
UPDATE maTable SET Statut = 'en cours', Attritution = 'Hector' 
WHERE Compteur = (SELECT MIN(Compteur) 
FROM maTable WHERE Statut = 'à traiter')

Comme on fait la manoeuvre en une seule instruction, on n'a pas vraiment besoin de transaction

Après, on fait :

Code :

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

1
2
SELECT * FROM maTable 
WHERE Statut = 'en cours' AND Attritution = 'Hector'

Sinon, pour être "ceinture et bretelles" avec une transaction, cela donne :

Code :

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

1
2
3
4
5
6
7
 
BEGIN TRANSACTION
UPDATE maTable SET Statut = 'en cours', Attritution = 'Hector' 
WHERE Compteur = (SELECT MIN(Compteur) FROM maTable WHERE Statut = 'à traiter')
SELECT * FROM maTable 
WHERE Statut = 'en cours' AND Attritution = 'Hector'
COMMIT

Si quelque chose foire au milieu, la base se remet dans son état d'avant la transaction