En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une
commande en modif en même temps.
Une liste de commandes est donc affichée dans un datagrid sur une page
Lorsque l'utilisateur clique sur une commande pour la traiter, je compte
faitre ainsi :
- stocker l'ID de la commande au moment de la sélection dans le datagrid
>> ajouter l'ID dans une variable statique de type HashTable déclarée dans
>> niveau global.asax.vb
>> ajouter l'ID dans une variable de session
- il faut enlever du Dataset affiché dans le datagrid les ID présents dans
la variable statique
>> avant de "binder" le dataset des commandes à traiter, on retire les enreg
>> présents dans la variable statique
- l'ID est enlevé de la variable statique lorsque l'utilisateur valide ou
annule le traitement de la commande
et la variable de session est réinitialisée
- l'ID doit être enlevé en cas de TimeOut de la session de l'utilisateur
>> on retire tous les ID des commandes associés à ce SessionID
- l'ID doit être enlevé lorsque l'utilisateur quitte la page de traiatement
des commandes par un autre chemin que celui prévu
pour ce traitement (cad sans cliquer sur valider ou annuler)
. je sêche ...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Merlin
> En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session. Imaginons qu'il doivent faire page x, page y, page z : quand il boucle page x, tu mets dans la session "pagex". Quand la page y est invoquée elle vérifie la présence de "pagex" dans la session, si pas là, elle affiche un message d'erreur et renvoie par pagex. Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte la chaîne automatiquement. Chaque page fait la même chose en testant donc son prédécesseur (la page z teste si "pagey" est dans la session. La dernière page, une fois validée, supprimme pagex, pagey et pagez de la session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu importe la méthode utilisée, surtout dans une appli web, tu risques d'avoir des cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans une table "CommandesEnCoursDeModif" avec le code commande, l'heure, le code session et le user éventuellement. Sur la fin de session d'un user dans global.Asax tu fais un "DELETE FROM CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à toi de voir). Sur la fin de l'application dans global Asax tu fais pareil en plus radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex, pagey etc de la session comme je le disais plus haut, tu fais aussi un Delete dans la table des commandes en cours de modif avec le code session du user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout es ok, si oui tu affiches un message "commande n°x en cours de modif par le user machin depuis telleheure" et tu interdis la chose ou bien tu autorises à modifier quand même (à voir)
--
///3rL1n____
> En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une
commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session.
Imaginons qu'il doivent faire page x, page y, page z : quand il boucle
page x, tu mets dans la session "pagex". Quand la page y est invoquée
elle vérifie la présence de "pagex" dans la session, si pas là, elle
affiche un message d'erreur et renvoie par pagex.
Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte
la chaîne automatiquement.
Chaque page fait la même chose en testant donc son prédécesseur (la
page z teste si "pagey" est dans la session.
La dernière page, une fois validée, supprimme pagex, pagey et pagez de
la session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu
importe la méthode utilisée, surtout dans une appli web, tu risques
d'avoir des cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans
une table "CommandesEnCoursDeModif" avec le code commande, l'heure, le
code session et le user éventuellement.
Sur la fin de session d'un user dans global.Asax tu fais un "DELETE
FROM CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à
toi de voir). Sur la fin de l'application dans global Asax tu fais
pareil en plus radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex,
pagey etc de la session comme je le disais plus haut, tu fais aussi un
Delete dans la table des commandes en cours de modif avec le code
session du user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table
CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout
es ok, si oui tu affiches un message "commande n°x en cours de modif
par le user machin depuis telleheure" et tu interdis la chose ou bien
tu autorises à modifier quand même (à voir)
> En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session. Imaginons qu'il doivent faire page x, page y, page z : quand il boucle page x, tu mets dans la session "pagex". Quand la page y est invoquée elle vérifie la présence de "pagex" dans la session, si pas là, elle affiche un message d'erreur et renvoie par pagex. Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte la chaîne automatiquement. Chaque page fait la même chose en testant donc son prédécesseur (la page z teste si "pagey" est dans la session. La dernière page, une fois validée, supprimme pagex, pagey et pagez de la session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu importe la méthode utilisée, surtout dans une appli web, tu risques d'avoir des cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans une table "CommandesEnCoursDeModif" avec le code commande, l'heure, le code session et le user éventuellement. Sur la fin de session d'un user dans global.Asax tu fais un "DELETE FROM CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à toi de voir). Sur la fin de l'application dans global Asax tu fais pareil en plus radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex, pagey etc de la session comme je le disais plus haut, tu fais aussi un Delete dans la table des commandes en cours de modif avec le code session du user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout es ok, si oui tu affiches un message "commande n°x en cours de modif par le user machin depuis telleheure" et tu interdis la chose ou bien tu autorises à modifier quand même (à voir)
--
///3rL1n____
Merlin
> En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session. Imaginons qu'il doivent faire page x, page y, page z : quand il boucle page x, tu mets dans la session "pagex". Quand la page y est invoquée elle vérifie la présence de "pagex" dans la session, si pas là, elle affiche un message d'erreur et renvoie par pagex. Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte la chaîne automatiquement. Chaque page fait la même chose en testant donc son prédécesseur (la page z teste si "pagey" est dans la session. La dernière page, une fois validée, supprimme pagex, pagey et pagez de la session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu importe la méthode utilisée, surtout dans une appli web, tu risques d'avoir des cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans une table "CommandesEnCoursDeModif" avec le code commande, l'heure, le code session et le user éventuellement. Sur la fin de session d'un user dans global.Asax tu fais un "DELETE FROM CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à toi de voir). Sur la fin de l'application dans global Asax tu fais pareil en plus radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex, pagey etc de la session comme je le disais plus haut, tu fais aussi un Delete dans la table des commandes en cours de modif avec le code session du user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout es ok, si oui tu affiches un message "commande n°x en cours de modif par le user machin depuis telleheure" et tu interdis la chose ou bien tu autorises à modifier quand même (à voir)
--
///3rL1n____
> En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une
commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session.
Imaginons qu'il doivent faire page x, page y, page z : quand il boucle
page x, tu mets dans la session "pagex". Quand la page y est invoquée
elle vérifie la présence de "pagex" dans la session, si pas là, elle
affiche un message d'erreur et renvoie par pagex.
Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte
la chaîne automatiquement.
Chaque page fait la même chose en testant donc son prédécesseur (la
page z teste si "pagey" est dans la session.
La dernière page, une fois validée, supprimme pagex, pagey et pagez de
la session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu
importe la méthode utilisée, surtout dans une appli web, tu risques
d'avoir des cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans
une table "CommandesEnCoursDeModif" avec le code commande, l'heure, le
code session et le user éventuellement.
Sur la fin de session d'un user dans global.Asax tu fais un "DELETE
FROM CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à
toi de voir). Sur la fin de l'application dans global Asax tu fais
pareil en plus radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex,
pagey etc de la session comme je le disais plus haut, tu fais aussi un
Delete dans la table des commandes en cours de modif avec le code
session du user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table
CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout
es ok, si oui tu affiches un message "commande n°x en cours de modif
par le user machin depuis telleheure" et tu interdis la chose ou bien
tu autorises à modifier quand même (à voir)
> En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session. Imaginons qu'il doivent faire page x, page y, page z : quand il boucle page x, tu mets dans la session "pagex". Quand la page y est invoquée elle vérifie la présence de "pagex" dans la session, si pas là, elle affiche un message d'erreur et renvoie par pagex. Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte la chaîne automatiquement. Chaque page fait la même chose en testant donc son prédécesseur (la page z teste si "pagey" est dans la session. La dernière page, une fois validée, supprimme pagex, pagey et pagez de la session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu importe la méthode utilisée, surtout dans une appli web, tu risques d'avoir des cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans une table "CommandesEnCoursDeModif" avec le code commande, l'heure, le code session et le user éventuellement. Sur la fin de session d'un user dans global.Asax tu fais un "DELETE FROM CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à toi de voir). Sur la fin de l'application dans global Asax tu fais pareil en plus radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex, pagey etc de la session comme je le disais plus haut, tu fais aussi un Delete dans la table des commandes en cours de modif avec le code session du user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout es ok, si oui tu affiches un message "commande n°x en cours de modif par le user machin depuis telleheure" et tu interdis la chose ou bien tu autorises à modifier quand même (à voir)
--
///3rL1n____
..
Ok, merci pour ta réponse, c'est une bonne idée. Ceci dit, c'est vrai que le coup en dév est moins lourd que ce que je pensais faire.
Merci encore
@+
Damien "Merlin" a écrit dans le message de news:
En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session. Imaginons qu'il doivent faire page x, page y, page z : quand il boucle page x, tu mets dans la session "pagex". Quand la page y est invoquée elle vérifie la présence de "pagex" dans la session, si pas là, elle affiche un message d'erreur et renvoie par pagex. Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte la chaîne automatiquement. Chaque page fait la même chose en testant donc son prédécesseur (la page z teste si "pagey" est dans la session. La dernière page, une fois validée, supprimme pagex, pagey et pagez de la session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu importe la méthode utilisée, surtout dans une appli web, tu risques d'avoir des cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans une table "CommandesEnCoursDeModif" avec le code commande, l'heure, le code session et le user éventuellement. Sur la fin de session d'un user dans global.Asax tu fais un "DELETE FROM CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à toi de voir). Sur la fin de l'application dans global Asax tu fais pareil en plus radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex, pagey etc de la session comme je le disais plus haut, tu fais aussi un Delete dans la table des commandes en cours de modif avec le code session du user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout es ok, si oui tu affiches un message "commande n°x en cours de modif par le user machin depuis telleheure" et tu interdis la chose ou bien tu autorises à modifier quand même (à voir)
--
///3rL1n____
Ok, merci pour ta réponse, c'est une bonne idée.
Ceci dit, c'est vrai que le coup en dév est moins lourd que ce que je
pensais faire.
Merci encore
@+
Damien
"Merlin" <Merlin@LesFees.Net> a écrit dans le message de news:
mn.14677d636f85662c.18651@LesFees.Net...
En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une
commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session.
Imaginons qu'il doivent faire page x, page y, page z : quand il boucle
page x, tu mets dans la session "pagex". Quand la page y est invoquée elle
vérifie la présence de "pagex" dans la session, si pas là, elle affiche un
message d'erreur et renvoie par pagex.
Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte la
chaîne automatiquement.
Chaque page fait la même chose en testant donc son prédécesseur (la page z
teste si "pagey" est dans la session.
La dernière page, une fois validée, supprimme pagex, pagey et pagez de la
session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu importe
la méthode utilisée, surtout dans une appli web, tu risques d'avoir des
cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans une
table "CommandesEnCoursDeModif" avec le code commande, l'heure, le code
session et le user éventuellement.
Sur la fin de session d'un user dans global.Asax tu fais un "DELETE FROM
CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à toi de
voir). Sur la fin de l'application dans global Asax tu fais pareil en plus
radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex, pagey
etc de la session comme je le disais plus haut, tu fais aussi un Delete
dans la table des commandes en cours de modif avec le code session du
user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table
CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout es
ok, si oui tu affiches un message "commande n°x en cours de modif par le
user machin depuis telleheure" et tu interdis la chose ou bien tu
autorises à modifier quand même (à voir)
Ok, merci pour ta réponse, c'est une bonne idée. Ceci dit, c'est vrai que le coup en dév est moins lourd que ce que je pensais faire.
Merci encore
@+
Damien "Merlin" a écrit dans le message de news:
En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session. Imaginons qu'il doivent faire page x, page y, page z : quand il boucle page x, tu mets dans la session "pagex". Quand la page y est invoquée elle vérifie la présence de "pagex" dans la session, si pas là, elle affiche un message d'erreur et renvoie par pagex. Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte la chaîne automatiquement. Chaque page fait la même chose en testant donc son prédécesseur (la page z teste si "pagey" est dans la session. La dernière page, une fois validée, supprimme pagex, pagey et pagez de la session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu importe la méthode utilisée, surtout dans une appli web, tu risques d'avoir des cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans une table "CommandesEnCoursDeModif" avec le code commande, l'heure, le code session et le user éventuellement. Sur la fin de session d'un user dans global.Asax tu fais un "DELETE FROM CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à toi de voir). Sur la fin de l'application dans global Asax tu fais pareil en plus radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex, pagey etc de la session comme je le disais plus haut, tu fais aussi un Delete dans la table des commandes en cours de modif avec le code session du user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout es ok, si oui tu affiches un message "commande n°x en cours de modif par le user machin depuis telleheure" et tu interdis la chose ou bien tu autorises à modifier quand même (à voir)
--
///3rL1n____
..
Ok, merci pour ta réponse, c'est une bonne idée. Ceci dit, c'est vrai que le coup en dév est moins lourd que ce que je pensais faire.
Merci encore
@+
Damien "Merlin" a écrit dans le message de news:
En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session. Imaginons qu'il doivent faire page x, page y, page z : quand il boucle page x, tu mets dans la session "pagex". Quand la page y est invoquée elle vérifie la présence de "pagex" dans la session, si pas là, elle affiche un message d'erreur et renvoie par pagex. Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte la chaîne automatiquement. Chaque page fait la même chose en testant donc son prédécesseur (la page z teste si "pagey" est dans la session. La dernière page, une fois validée, supprimme pagex, pagey et pagez de la session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu importe la méthode utilisée, surtout dans une appli web, tu risques d'avoir des cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans une table "CommandesEnCoursDeModif" avec le code commande, l'heure, le code session et le user éventuellement. Sur la fin de session d'un user dans global.Asax tu fais un "DELETE FROM CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à toi de voir). Sur la fin de l'application dans global Asax tu fais pareil en plus radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex, pagey etc de la session comme je le disais plus haut, tu fais aussi un Delete dans la table des commandes en cours de modif avec le code session du user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout es ok, si oui tu affiches un message "commande n°x en cours de modif par le user machin depuis telleheure" et tu interdis la chose ou bien tu autorises à modifier quand même (à voir)
--
///3rL1n____
Ok, merci pour ta réponse, c'est une bonne idée.
Ceci dit, c'est vrai que le coup en dév est moins lourd que ce que je
pensais faire.
Merci encore
@+
Damien
"Merlin" <Merlin@LesFees.Net> a écrit dans le message de news:
mn.14677d636f85662c.18651@LesFees.Net...
En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une
commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session.
Imaginons qu'il doivent faire page x, page y, page z : quand il boucle
page x, tu mets dans la session "pagex". Quand la page y est invoquée elle
vérifie la présence de "pagex" dans la session, si pas là, elle affiche un
message d'erreur et renvoie par pagex.
Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte la
chaîne automatiquement.
Chaque page fait la même chose en testant donc son prédécesseur (la page z
teste si "pagey" est dans la session.
La dernière page, une fois validée, supprimme pagex, pagey et pagez de la
session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu importe
la méthode utilisée, surtout dans une appli web, tu risques d'avoir des
cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans une
table "CommandesEnCoursDeModif" avec le code commande, l'heure, le code
session et le user éventuellement.
Sur la fin de session d'un user dans global.Asax tu fais un "DELETE FROM
CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à toi de
voir). Sur la fin de l'application dans global Asax tu fais pareil en plus
radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex, pagey
etc de la session comme je le disais plus haut, tu fais aussi un Delete
dans la table des commandes en cours de modif avec le code session du
user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table
CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout es
ok, si oui tu affiches un message "commande n°x en cours de modif par le
user machin depuis telleheure" et tu interdis la chose ou bien tu
autorises à modifier quand même (à voir)
Ok, merci pour ta réponse, c'est une bonne idée. Ceci dit, c'est vrai que le coup en dév est moins lourd que ce que je pensais faire.
Merci encore
@+
Damien "Merlin" a écrit dans le message de news:
En quelques mots, je souhaite éviter que plusieurs utilisateurs ouvre une commande en modif en même temps.
Pour tracer le chemin de l'utilisateur tu peux utiliser la session. Imaginons qu'il doivent faire page x, page y, page z : quand il boucle page x, tu mets dans la session "pagex". Quand la page y est invoquée elle vérifie la présence de "pagex" dans la session, si pas là, elle affiche un message d'erreur et renvoie par pagex. Si pagex a un prédécesseur elle fait pareil, etc. Comme ça ça remonte la chaîne automatiquement. Chaque page fait la même chose en testant donc son prédécesseur (la page z teste si "pagey" est dans la session. La dernière page, une fois validée, supprimme pagex, pagey et pagez de la session.
Maintenant pour le "lock" des commandes, tu vas t'enquiquiner, peu importe la méthode utilisée, surtout dans une appli web, tu risques d'avoir des cas foireux.
Mais bon tu peux essayer un schéma de ce genre :
Quand on entre en modif dans la commande C, tu ajoutes un record dans une table "CommandesEnCoursDeModif" avec le code commande, l'heure, le code session et le user éventuellement. Sur la fin de session d'un user dans global.Asax tu fais un "DELETE FROM CommandesEnCoursDeModif Where CodeSession = xxxx" (ou code user à toi de voir). Sur la fin de l'application dans global Asax tu fais pareil en plus radical "DELETE FROM CommandesEnCoursDeModif".
Dans le parcours de saisie de commande, là où tu effaces les pagex, pagey etc de la session comme je le disais plus haut, tu fais aussi un Delete dans la table des commandes en cours de modif avec le code session du user, ou le n° de commande, à voir selon le plus pratique.
Quand on entre en modif sur la commande C tu verifies dans la table CommandesEnCoursdeModif si le n° de commande est présent. Si non, tout es ok, si oui tu affiches un message "commande n°x en cours de modif par le user machin depuis telleheure" et tu interdis la chose ou bien tu autorises à modifier quand même (à voir)
--
///3rL1n____
Merlin
> Ok, merci pour ta réponse, c'est une bonne idée. Ceci dit, c'est vrai que le coup en dév est moins lourd que ce que je pensais faire.
plus c'est simple, moins ça risque de bugger, adage de notre beau métier qui se vérifie avec tous les langages et tous les OS depuis toujours :-)
--
///3rL1n____
> Ok, merci pour ta réponse, c'est une bonne idée.
Ceci dit, c'est vrai que le coup en dév est moins lourd que ce que je pensais
faire.
plus c'est simple, moins ça risque de bugger, adage de notre beau
métier qui se vérifie avec tous les langages et tous les OS depuis
toujours :-)
