Bonjour,
Juanito a écrit:En fait, le développement que je fais est en Web et la crainte que j'ai
est que s'il y a coupure de ligne ou un plantage qualconque, on se
retrouve avec des lignes qui sont condidérées comme bloquées alors que
cela n'est pas le cas.
Désolé, mais là c'est du domaine de la science-fiction.
Ce que tu veux
faire est utopique : dans un contexte web, il n'y a ni session, ni
plantage. Une page web est délivrée sur le client, et ensuite tout lien
avec le serveur est coupé. Si ton utilisateur clique sur le bouton
validation deux semaines après avoir chargé la page, que veux-tu qu'il
se passe ?
Qu'est-ce qu'un plantage dans un contexte de client web ?
Bonjour,
Juanito a écrit:
En fait, le développement que je fais est en Web et la crainte que j'ai
est que s'il y a coupure de ligne ou un plantage qualconque, on se
retrouve avec des lignes qui sont condidérées comme bloquées alors que
cela n'est pas le cas.
Désolé, mais là c'est du domaine de la science-fiction.
Ce que tu veux
faire est utopique : dans un contexte web, il n'y a ni session, ni
plantage. Une page web est délivrée sur le client, et ensuite tout lien
avec le serveur est coupé. Si ton utilisateur clique sur le bouton
validation deux semaines après avoir chargé la page, que veux-tu qu'il
se passe ?
Qu'est-ce qu'un plantage dans un contexte de client web ?
Bonjour,
Juanito a écrit:En fait, le développement que je fais est en Web et la crainte que j'ai
est que s'il y a coupure de ligne ou un plantage qualconque, on se
retrouve avec des lignes qui sont condidérées comme bloquées alors que
cela n'est pas le cas.
Désolé, mais là c'est du domaine de la science-fiction.
Ce que tu veux
faire est utopique : dans un contexte web, il n'y a ni session, ni
plantage. Une page web est délivrée sur le client, et ensuite tout lien
avec le serveur est coupé. Si ton utilisateur clique sur le bouton
validation deux semaines après avoir chargé la page, que veux-tu qu'il
se passe ?
Qu'est-ce qu'un plantage dans un contexte de client web ?
Bonjour,
En fait, j'ai travaillé avant avec des gestionnaires de fichiers indexés
dans lesquels il y a des ordres de lecture bloquantes et des déblocages.
On peut donc lire et bloquer un enregistrement, faire plein de
traitements, de saisie ... et à la fin mémoriser et débloquer. Si un
autre poste essaie de faire une lecture blocante sur le même
enregistrement cela renvoie un mesasge d'erreur. J'aimerais reproduire
la même chose.
Bonjour,
En fait, j'ai travaillé avant avec des gestionnaires de fichiers indexés
dans lesquels il y a des ordres de lecture bloquantes et des déblocages.
On peut donc lire et bloquer un enregistrement, faire plein de
traitements, de saisie ... et à la fin mémoriser et débloquer. Si un
autre poste essaie de faire une lecture blocante sur le même
enregistrement cela renvoie un mesasge d'erreur. J'aimerais reproduire
la même chose.
Bonjour,
En fait, j'ai travaillé avant avec des gestionnaires de fichiers indexés
dans lesquels il y a des ordres de lecture bloquantes et des déblocages.
On peut donc lire et bloquer un enregistrement, faire plein de
traitements, de saisie ... et à la fin mémoriser et débloquer. Si un
autre poste essaie de faire une lecture blocante sur le même
enregistrement cela renvoie un mesasge d'erreur. J'aimerais reproduire
la même chose.
Juanito a écrit :Bonjour,
[...]En fait, j'ai travaillé avant avec des gestionnaires de fichiers indexés
dans lesquels il y a des ordres de lecture bloquantes et des déblocages. On
peut donc lire et bloquer un enregistrement, faire plein de traitements, de
saisie ... et à la fin mémoriser et débloquer. Si un autre poste essaie de
faire une lecture blocante sur le même enregistrement cela renvoie un
mesasge d'erreur. J'aimerais reproduire la même chose.
D'ou vos question et votre erreur !
C'est le SGBDR qui fait tout cela de manière automatique...
Commencez par apprendre comment fonctionne un SGBDR. A partir de là vous
aurez compris que vos questions n'ont aucun sens...
Mon site web comme mes bouquins peuvent vous y aider !
A +
Juanito a écrit :
Bonjour,
[...]
En fait, j'ai travaillé avant avec des gestionnaires de fichiers indexés
dans lesquels il y a des ordres de lecture bloquantes et des déblocages. On
peut donc lire et bloquer un enregistrement, faire plein de traitements, de
saisie ... et à la fin mémoriser et débloquer. Si un autre poste essaie de
faire une lecture blocante sur le même enregistrement cela renvoie un
mesasge d'erreur. J'aimerais reproduire la même chose.
D'ou vos question et votre erreur !
C'est le SGBDR qui fait tout cela de manière automatique...
Commencez par apprendre comment fonctionne un SGBDR. A partir de là vous
aurez compris que vos questions n'ont aucun sens...
Mon site web comme mes bouquins peuvent vous y aider !
A +
Juanito a écrit :Bonjour,
[...]En fait, j'ai travaillé avant avec des gestionnaires de fichiers indexés
dans lesquels il y a des ordres de lecture bloquantes et des déblocages. On
peut donc lire et bloquer un enregistrement, faire plein de traitements, de
saisie ... et à la fin mémoriser et débloquer. Si un autre poste essaie de
faire une lecture blocante sur le même enregistrement cela renvoie un
mesasge d'erreur. J'aimerais reproduire la même chose.
D'ou vos question et votre erreur !
C'est le SGBDR qui fait tout cela de manière automatique...
Commencez par apprendre comment fonctionne un SGBDR. A partir de là vous
aurez compris que vos questions n'ont aucun sens...
Mon site web comme mes bouquins peuvent vous y aider !
A +
Bonjour,
Je comprends très bien que le Sgbdr gère les blocages durant les update.
Cependant ce que je voudrais c'est réserver une ligne d'une table pour
que les autres utilisateurs ne puissent pas l'utiliser. Même pendant
plusieurs minutes.
A ouvre un client
B ouvre le même client
A fait des modifs et les mémorise
B fait d'autres modifications et les mémorise
En fait, lorsque A rappelle le client il ne voit plus ses modifs mais
celles effectuées par B.
Soit le dernier qui mémorise gagne, soit on regarde par rapport à une
colonne timestamp mise à jour lors des mémorisations et on indique que
quelqu'un d'autre a fait des modifs entre temps et on refuse de mémoriser.
Je préférerais indiquer un message à l'ouverture de la fiche du client
que quelqu'un d'autre est en train de le modifier et qu'il ne peut pas
le faire actuellement.
Donc, si on ne peut pas bloquer une ligne je pourrais gérer ces
semblants de blocages par une table dans laquelle je mettrais le nom de
la table concernée, l'identifiant unique, l'utilisateur, la date et
l'heure ... Pour "bloquer" une ligne j'ajoute dans cette table et pour
"débloquer" je l'efface.
Mais d'où ma remarque en cas de plantage ou de coupure de réseau. Cette
table contiendra des lignes considérées comme bloquées alors que cela
n'est pas le cas.
J'ai effectivement regardé votre site et parcouru un de vos livres. Cela
m'a appris beaucoup mais je n'ai pas trouvé de réponse à cette question.
Cordialement
Jean
Fred BROUARD avait prétendu :Juanito a écrit :Bonjour,
[...]En fait, j'ai travaillé avant avec des gestionnaires de fichiers
indexés dans lesquels il y a des ordres de lecture bloquantes et des
déblocages. On peut donc lire et bloquer un enregistrement, faire
plein de traitements, de saisie ... et à la fin mémoriser et
débloquer. Si un autre poste essaie de faire une lecture blocante sur
le même enregistrement cela renvoie un mesasge d'erreur. J'aimerais
reproduire la même chose.
D'ou vos question et votre erreur !
C'est le SGBDR qui fait tout cela de manière automatique...
Commencez par apprendre comment fonctionne un SGBDR. A partir de là
vous aurez compris que vos questions n'ont aucun sens...
Mon site web comme mes bouquins peuvent vous y aider !
A +
Bonjour,
Je comprends très bien que le Sgbdr gère les blocages durant les update.
Cependant ce que je voudrais c'est réserver une ligne d'une table pour
que les autres utilisateurs ne puissent pas l'utiliser. Même pendant
plusieurs minutes.
A ouvre un client
B ouvre le même client
A fait des modifs et les mémorise
B fait d'autres modifications et les mémorise
En fait, lorsque A rappelle le client il ne voit plus ses modifs mais
celles effectuées par B.
Soit le dernier qui mémorise gagne, soit on regarde par rapport à une
colonne timestamp mise à jour lors des mémorisations et on indique que
quelqu'un d'autre a fait des modifs entre temps et on refuse de mémoriser.
Je préférerais indiquer un message à l'ouverture de la fiche du client
que quelqu'un d'autre est en train de le modifier et qu'il ne peut pas
le faire actuellement.
Donc, si on ne peut pas bloquer une ligne je pourrais gérer ces
semblants de blocages par une table dans laquelle je mettrais le nom de
la table concernée, l'identifiant unique, l'utilisateur, la date et
l'heure ... Pour "bloquer" une ligne j'ajoute dans cette table et pour
"débloquer" je l'efface.
Mais d'où ma remarque en cas de plantage ou de coupure de réseau. Cette
table contiendra des lignes considérées comme bloquées alors que cela
n'est pas le cas.
J'ai effectivement regardé votre site et parcouru un de vos livres. Cela
m'a appris beaucoup mais je n'ai pas trouvé de réponse à cette question.
Cordialement
Jean
Fred BROUARD avait prétendu :
Juanito a écrit :
Bonjour,
[...]
En fait, j'ai travaillé avant avec des gestionnaires de fichiers
indexés dans lesquels il y a des ordres de lecture bloquantes et des
déblocages. On peut donc lire et bloquer un enregistrement, faire
plein de traitements, de saisie ... et à la fin mémoriser et
débloquer. Si un autre poste essaie de faire une lecture blocante sur
le même enregistrement cela renvoie un mesasge d'erreur. J'aimerais
reproduire la même chose.
D'ou vos question et votre erreur !
C'est le SGBDR qui fait tout cela de manière automatique...
Commencez par apprendre comment fonctionne un SGBDR. A partir de là
vous aurez compris que vos questions n'ont aucun sens...
Mon site web comme mes bouquins peuvent vous y aider !
A +
Bonjour,
Je comprends très bien que le Sgbdr gère les blocages durant les update.
Cependant ce que je voudrais c'est réserver une ligne d'une table pour
que les autres utilisateurs ne puissent pas l'utiliser. Même pendant
plusieurs minutes.
A ouvre un client
B ouvre le même client
A fait des modifs et les mémorise
B fait d'autres modifications et les mémorise
En fait, lorsque A rappelle le client il ne voit plus ses modifs mais
celles effectuées par B.
Soit le dernier qui mémorise gagne, soit on regarde par rapport à une
colonne timestamp mise à jour lors des mémorisations et on indique que
quelqu'un d'autre a fait des modifs entre temps et on refuse de mémoriser.
Je préférerais indiquer un message à l'ouverture de la fiche du client
que quelqu'un d'autre est en train de le modifier et qu'il ne peut pas
le faire actuellement.
Donc, si on ne peut pas bloquer une ligne je pourrais gérer ces
semblants de blocages par une table dans laquelle je mettrais le nom de
la table concernée, l'identifiant unique, l'utilisateur, la date et
l'heure ... Pour "bloquer" une ligne j'ajoute dans cette table et pour
"débloquer" je l'efface.
Mais d'où ma remarque en cas de plantage ou de coupure de réseau. Cette
table contiendra des lignes considérées comme bloquées alors que cela
n'est pas le cas.
J'ai effectivement regardé votre site et parcouru un de vos livres. Cela
m'a appris beaucoup mais je n'ai pas trouvé de réponse à cette question.
Cordialement
Jean
Fred BROUARD avait prétendu :Juanito a écrit :Bonjour,
[...]En fait, j'ai travaillé avant avec des gestionnaires de fichiers
indexés dans lesquels il y a des ordres de lecture bloquantes et des
déblocages. On peut donc lire et bloquer un enregistrement, faire
plein de traitements, de saisie ... et à la fin mémoriser et
débloquer. Si un autre poste essaie de faire une lecture blocante sur
le même enregistrement cela renvoie un mesasge d'erreur. J'aimerais
reproduire la même chose.
D'ou vos question et votre erreur !
C'est le SGBDR qui fait tout cela de manière automatique...
Commencez par apprendre comment fonctionne un SGBDR. A partir de là
vous aurez compris que vos questions n'ont aucun sens...
Mon site web comme mes bouquins peuvent vous y aider !
A +
Juanito a écrit :Bonjour,
Je comprends très bien que le Sgbdr gère les blocages durant les update.
Cependant ce que je voudrais c'est réserver une ligne d'une table pour que
les autres utilisateurs ne puissent pas l'utiliser. Même pendant plusieurs
minutes.
A ouvre un client
B ouvre le même client
la notion de client n'existe pas dans un SGBDR. On parle de table de
lignes...
Qu'est ce qu'un client ? Une ligne dans une table ???
Pour moi un client est un objet composé de plusieurs tables :
table des personnes (générique) avec nom, prenom
Table des "clients" (spécifique : héritage) avec remise et enseigne par
exemple
table des téléphones
table des adressees
table des mails
..
Vous voudriez bloquer tout cela pour pendant 10 minutes juste pour une modif
?
Nous ne vivons pas dans le même monde. Vous en êtes resté aux fichiers plat
dans lequel figure tout un tas d'informations inutile.
Votre volonté de vouloir reproduire le monde des fichiers plat est inutiles,
stérile et dangereuse et fait mon bonheur en matière de conseil et d'audit.
C'est là que je trouve le max de pognon à gagner parce que les applications
deviennent catastrophiquement lente et son inexploitable dès qu'il y a un peu
de volume.
Donc il faut tout casser et produire un modèle relationnel. Soit quelques
dizaines de jours de conseil, d'audit et cie facturé en moyenne 900 ¤ HT /
j.
Je vous renouvelle donc mon conseil : apprenez ce que sont les SGBDR...A fait des modifs et les mémorise
B fait d'autres modifications et les mémorise
En fait, lorsque A rappelle le client il ne voit plus ses modifs mais
celles effectuées par B.
Soit le dernier qui mémorise gagne, soit on regarde par rapport à une
colonne timestamp mise à jour lors des mémorisations et on indique que
quelqu'un d'autre a fait des modifs entre temps et on refuse de mémoriser.
Je préférerais indiquer un message à l'ouverture de la fiche du client
il n'y a pas de "fiche " dans un SGBDR !!!que quelqu'un d'autre est en train de le modifier et qu'il ne peut pas le
faire actuellement.
Donc, si on ne peut pas bloquer une ligne je pourrais gérer ces semblants
de blocages par une table dans laquelle je mettrais le nom de la table
concernée, l'identifiant unique, l'utilisateur, la date et l'heure ... Pour
"bloquer" une ligne j'ajoute dans cette table et pour "débloquer" je
l'efface.
Usine à gaz !!!
Mais d'où ma remarque en cas de plantage ou de coupure de réseau. Cette
table contiendra des lignes considérées comme bloquées alors que cela n'est
pas le cas.
Et oui... et comment faite vous pour distinguer les vrais blocage des faux
??? Si le client s'est reconnecté après un plantage par exemple ??? Vous
aller auditer le réseau et avoir une table des trames TCP émises ??? Et si
l'auditeur de trame réseau est lui même sur une banche défaillante du réseau
????????
ect, etc, ect...
J'ai effectivement regardé votre site et parcouru un de vos livres. Cela
m'a appris beaucoup mais je n'ai pas trouvé de réponse à cette question.
Ne cherchez pas votre question n'a aucun sens !Cordialement
Jean
A +
Fred BROUARD avait prétendu :Juanito a écrit :Bonjour,
[...]En fait, j'ai travaillé avant avec des gestionnaires de fichiers indexés
dans lesquels il y a des ordres de lecture bloquantes et des déblocages.
On peut donc lire et bloquer un enregistrement, faire plein de
traitements, de saisie ... et à la fin mémoriser et débloquer. Si un
autre poste essaie de faire une lecture blocante sur le même
enregistrement cela renvoie un mesasge d'erreur. J'aimerais reproduire la
même chose.
D'ou vos question et votre erreur !
C'est le SGBDR qui fait tout cela de manière automatique...
Commencez par apprendre comment fonctionne un SGBDR. A partir de là vous
aurez compris que vos questions n'ont aucun sens...
Mon site web comme mes bouquins peuvent vous y aider !
A +
Juanito a écrit :
Bonjour,
Je comprends très bien que le Sgbdr gère les blocages durant les update.
Cependant ce que je voudrais c'est réserver une ligne d'une table pour que
les autres utilisateurs ne puissent pas l'utiliser. Même pendant plusieurs
minutes.
A ouvre un client
B ouvre le même client
la notion de client n'existe pas dans un SGBDR. On parle de table de
lignes...
Qu'est ce qu'un client ? Une ligne dans une table ???
Pour moi un client est un objet composé de plusieurs tables :
table des personnes (générique) avec nom, prenom
Table des "clients" (spécifique : héritage) avec remise et enseigne par
exemple
table des téléphones
table des adressees
table des mails
..
Vous voudriez bloquer tout cela pour pendant 10 minutes juste pour une modif
?
Nous ne vivons pas dans le même monde. Vous en êtes resté aux fichiers plat
dans lequel figure tout un tas d'informations inutile.
Votre volonté de vouloir reproduire le monde des fichiers plat est inutiles,
stérile et dangereuse et fait mon bonheur en matière de conseil et d'audit.
C'est là que je trouve le max de pognon à gagner parce que les applications
deviennent catastrophiquement lente et son inexploitable dès qu'il y a un peu
de volume.
Donc il faut tout casser et produire un modèle relationnel. Soit quelques
dizaines de jours de conseil, d'audit et cie facturé en moyenne 900 ¤ HT /
j.
Je vous renouvelle donc mon conseil : apprenez ce que sont les SGBDR...
A fait des modifs et les mémorise
B fait d'autres modifications et les mémorise
En fait, lorsque A rappelle le client il ne voit plus ses modifs mais
celles effectuées par B.
Soit le dernier qui mémorise gagne, soit on regarde par rapport à une
colonne timestamp mise à jour lors des mémorisations et on indique que
quelqu'un d'autre a fait des modifs entre temps et on refuse de mémoriser.
Je préférerais indiquer un message à l'ouverture de la fiche du client
il n'y a pas de "fiche " dans un SGBDR !!!
que quelqu'un d'autre est en train de le modifier et qu'il ne peut pas le
faire actuellement.
Donc, si on ne peut pas bloquer une ligne je pourrais gérer ces semblants
de blocages par une table dans laquelle je mettrais le nom de la table
concernée, l'identifiant unique, l'utilisateur, la date et l'heure ... Pour
"bloquer" une ligne j'ajoute dans cette table et pour "débloquer" je
l'efface.
Usine à gaz !!!
Mais d'où ma remarque en cas de plantage ou de coupure de réseau. Cette
table contiendra des lignes considérées comme bloquées alors que cela n'est
pas le cas.
Et oui... et comment faite vous pour distinguer les vrais blocage des faux
??? Si le client s'est reconnecté après un plantage par exemple ??? Vous
aller auditer le réseau et avoir une table des trames TCP émises ??? Et si
l'auditeur de trame réseau est lui même sur une banche défaillante du réseau
????????
ect, etc, ect...
J'ai effectivement regardé votre site et parcouru un de vos livres. Cela
m'a appris beaucoup mais je n'ai pas trouvé de réponse à cette question.
Ne cherchez pas votre question n'a aucun sens !
Cordialement
Jean
A +
Fred BROUARD avait prétendu :
Juanito a écrit :
Bonjour,
[...]
En fait, j'ai travaillé avant avec des gestionnaires de fichiers indexés
dans lesquels il y a des ordres de lecture bloquantes et des déblocages.
On peut donc lire et bloquer un enregistrement, faire plein de
traitements, de saisie ... et à la fin mémoriser et débloquer. Si un
autre poste essaie de faire une lecture blocante sur le même
enregistrement cela renvoie un mesasge d'erreur. J'aimerais reproduire la
même chose.
D'ou vos question et votre erreur !
C'est le SGBDR qui fait tout cela de manière automatique...
Commencez par apprendre comment fonctionne un SGBDR. A partir de là vous
aurez compris que vos questions n'ont aucun sens...
Mon site web comme mes bouquins peuvent vous y aider !
A +
Juanito a écrit :Bonjour,
Je comprends très bien que le Sgbdr gère les blocages durant les update.
Cependant ce que je voudrais c'est réserver une ligne d'une table pour que
les autres utilisateurs ne puissent pas l'utiliser. Même pendant plusieurs
minutes.
A ouvre un client
B ouvre le même client
la notion de client n'existe pas dans un SGBDR. On parle de table de
lignes...
Qu'est ce qu'un client ? Une ligne dans une table ???
Pour moi un client est un objet composé de plusieurs tables :
table des personnes (générique) avec nom, prenom
Table des "clients" (spécifique : héritage) avec remise et enseigne par
exemple
table des téléphones
table des adressees
table des mails
..
Vous voudriez bloquer tout cela pour pendant 10 minutes juste pour une modif
?
Nous ne vivons pas dans le même monde. Vous en êtes resté aux fichiers plat
dans lequel figure tout un tas d'informations inutile.
Votre volonté de vouloir reproduire le monde des fichiers plat est inutiles,
stérile et dangereuse et fait mon bonheur en matière de conseil et d'audit.
C'est là que je trouve le max de pognon à gagner parce que les applications
deviennent catastrophiquement lente et son inexploitable dès qu'il y a un peu
de volume.
Donc il faut tout casser et produire un modèle relationnel. Soit quelques
dizaines de jours de conseil, d'audit et cie facturé en moyenne 900 ¤ HT /
j.
Je vous renouvelle donc mon conseil : apprenez ce que sont les SGBDR...A fait des modifs et les mémorise
B fait d'autres modifications et les mémorise
En fait, lorsque A rappelle le client il ne voit plus ses modifs mais
celles effectuées par B.
Soit le dernier qui mémorise gagne, soit on regarde par rapport à une
colonne timestamp mise à jour lors des mémorisations et on indique que
quelqu'un d'autre a fait des modifs entre temps et on refuse de mémoriser.
Je préférerais indiquer un message à l'ouverture de la fiche du client
il n'y a pas de "fiche " dans un SGBDR !!!que quelqu'un d'autre est en train de le modifier et qu'il ne peut pas le
faire actuellement.
Donc, si on ne peut pas bloquer une ligne je pourrais gérer ces semblants
de blocages par une table dans laquelle je mettrais le nom de la table
concernée, l'identifiant unique, l'utilisateur, la date et l'heure ... Pour
"bloquer" une ligne j'ajoute dans cette table et pour "débloquer" je
l'efface.
Usine à gaz !!!
Mais d'où ma remarque en cas de plantage ou de coupure de réseau. Cette
table contiendra des lignes considérées comme bloquées alors que cela n'est
pas le cas.
Et oui... et comment faite vous pour distinguer les vrais blocage des faux
??? Si le client s'est reconnecté après un plantage par exemple ??? Vous
aller auditer le réseau et avoir une table des trames TCP émises ??? Et si
l'auditeur de trame réseau est lui même sur une banche défaillante du réseau
????????
ect, etc, ect...
J'ai effectivement regardé votre site et parcouru un de vos livres. Cela
m'a appris beaucoup mais je n'ai pas trouvé de réponse à cette question.
Ne cherchez pas votre question n'a aucun sens !Cordialement
Jean
A +
Fred BROUARD avait prétendu :Juanito a écrit :Bonjour,
[...]En fait, j'ai travaillé avant avec des gestionnaires de fichiers indexés
dans lesquels il y a des ordres de lecture bloquantes et des déblocages.
On peut donc lire et bloquer un enregistrement, faire plein de
traitements, de saisie ... et à la fin mémoriser et débloquer. Si un
autre poste essaie de faire une lecture blocante sur le même
enregistrement cela renvoie un mesasge d'erreur. J'aimerais reproduire la
même chose.
D'ou vos question et votre erreur !
C'est le SGBDR qui fait tout cela de manière automatique...
Commencez par apprendre comment fonctionne un SGBDR. A partir de là vous
aurez compris que vos questions n'ont aucun sens...
Mon site web comme mes bouquins peuvent vous y aider !
A +
Bonjour,
Juanito a écrit:En fait, le développement que je fais est en Web et la crainte que j'ai
est que s'il y a coupure de ligne ou un plantage qualconque, on se
retrouve avec des lignes qui sont condidérées comme bloquées alors que
cela n'est pas le cas.
Désolé, mais là c'est du domaine de la science-fiction. Ce que tu veux
faire est utopique : dans un contexte web, il n'y a ni session, ni
plantage. Une page web est délivrée sur le client, et ensuite tout lien
avec le serveur est coupé. Si ton utilisateur clique sur le bouton
validation deux semaines après avoir chargé la page, que veux-tu qu'il
se passe ?
Bonjour,
Juanito a écrit:
En fait, le développement que je fais est en Web et la crainte que j'ai
est que s'il y a coupure de ligne ou un plantage qualconque, on se
retrouve avec des lignes qui sont condidérées comme bloquées alors que
cela n'est pas le cas.
Désolé, mais là c'est du domaine de la science-fiction. Ce que tu veux
faire est utopique : dans un contexte web, il n'y a ni session, ni
plantage. Une page web est délivrée sur le client, et ensuite tout lien
avec le serveur est coupé. Si ton utilisateur clique sur le bouton
validation deux semaines après avoir chargé la page, que veux-tu qu'il
se passe ?
Bonjour,
Juanito a écrit:En fait, le développement que je fais est en Web et la crainte que j'ai
est que s'il y a coupure de ligne ou un plantage qualconque, on se
retrouve avec des lignes qui sont condidérées comme bloquées alors que
cela n'est pas le cas.
Désolé, mais là c'est du domaine de la science-fiction. Ce que tu veux
faire est utopique : dans un contexte web, il n'y a ni session, ni
plantage. Une page web est délivrée sur le client, et ensuite tout lien
avec le serveur est coupé. Si ton utilisateur clique sur le bouton
validation deux semaines après avoir chargé la page, que veux-tu qu'il
se passe ?
Salut Rudi :-)
"Rudi Bruchez" <rudi#nospam#at#babaluga.com> a écrit dans le message de news:Bonjour,
Juanito a écrit:En fait, le développement que je fais est en Web et la crainte que j'ai
est que s'il y a coupure de ligne ou un plantage qualconque, on se
retrouve avec des lignes qui sont condidérées comme bloquées alors que
cela n'est pas le cas.
Désolé, mais là c'est du domaine de la science-fiction. Ce que tu veux
faire est utopique : dans un contexte web, il n'y a ni session, ni
plantage. Une page web est délivrée sur le client, et ensuite tout lien
avec le serveur est coupé. Si ton utilisateur clique sur le bouton
validation deux semaines après avoir chargé la page, que veux-tu qu'il
se passe ?
Le "pseudo lock" peut simplement avoir une durée de vie. Ce délai passé,
l'utilisateur perd son tour, l'enregistrement redevient modifiable par
autrui. Notre utilisateur en validant son bouton au bout de deux semaines
aura un beau message lui expliquant tout cela car avant de valider
l'application vérifiera qu'il est bien le détenteur du lock et/ou que
l'enregistrement n'a pas été modifié entre temps. J'ai déjà implémenté cela
pour une appli web (Php/mySql) sans trop de souci. Il y a donc un processus
qui se charge de "nettoyer" ces anciens locks.
A+ Côme
Salut Rudi :-)
"Rudi Bruchez" <rudi#nospam#at#babaluga.com> a écrit dans le message de news:
Oa66rhrNIHA.1184@TK2MSFTNGP04.phx.gbl...
Bonjour,
Juanito a écrit:
En fait, le développement que je fais est en Web et la crainte que j'ai
est que s'il y a coupure de ligne ou un plantage qualconque, on se
retrouve avec des lignes qui sont condidérées comme bloquées alors que
cela n'est pas le cas.
Désolé, mais là c'est du domaine de la science-fiction. Ce que tu veux
faire est utopique : dans un contexte web, il n'y a ni session, ni
plantage. Une page web est délivrée sur le client, et ensuite tout lien
avec le serveur est coupé. Si ton utilisateur clique sur le bouton
validation deux semaines après avoir chargé la page, que veux-tu qu'il
se passe ?
Le "pseudo lock" peut simplement avoir une durée de vie. Ce délai passé,
l'utilisateur perd son tour, l'enregistrement redevient modifiable par
autrui. Notre utilisateur en validant son bouton au bout de deux semaines
aura un beau message lui expliquant tout cela car avant de valider
l'application vérifiera qu'il est bien le détenteur du lock et/ou que
l'enregistrement n'a pas été modifié entre temps. J'ai déjà implémenté cela
pour une appli web (Php/mySql) sans trop de souci. Il y a donc un processus
qui se charge de "nettoyer" ces anciens locks.
A+ Côme
Salut Rudi :-)
"Rudi Bruchez" <rudi#nospam#at#babaluga.com> a écrit dans le message de news:Bonjour,
Juanito a écrit:En fait, le développement que je fais est en Web et la crainte que j'ai
est que s'il y a coupure de ligne ou un plantage qualconque, on se
retrouve avec des lignes qui sont condidérées comme bloquées alors que
cela n'est pas le cas.
Désolé, mais là c'est du domaine de la science-fiction. Ce que tu veux
faire est utopique : dans un contexte web, il n'y a ni session, ni
plantage. Une page web est délivrée sur le client, et ensuite tout lien
avec le serveur est coupé. Si ton utilisateur clique sur le bouton
validation deux semaines après avoir chargé la page, que veux-tu qu'il
se passe ?
Le "pseudo lock" peut simplement avoir une durée de vie. Ce délai passé,
l'utilisateur perd son tour, l'enregistrement redevient modifiable par
autrui. Notre utilisateur en validant son bouton au bout de deux semaines
aura un beau message lui expliquant tout cela car avant de valider
l'application vérifiera qu'il est bien le détenteur du lock et/ou que
l'enregistrement n'a pas été modifié entre temps. J'ai déjà implémenté cela
pour une appli web (Php/mySql) sans trop de souci. Il y a donc un processus
qui se charge de "nettoyer" ces anciens locks.
A+ Côme
Le "pseudo lock" peut simplement avoir une durée de vie. Ce délai passé,
l'utilisateur perd son tour, l'enregistrement redevient modifiable par autrui.
Notre utilisateur en validant son bouton au bout de deux semaines aura un beau
message lui expliquant tout cela car avant de valider l'application vérifiera
qu'il est bien le détenteur du lock et/ou que l'enregistrement n'a pas été
modifié entre temps. J'ai déjà implémenté cela pour une appli web (Php/mySql)
sans trop de souci. Il y a donc un processus qui se charge de "nettoyer" ces
anciens locks.
Le "pseudo lock" peut simplement avoir une durée de vie. Ce délai passé,
l'utilisateur perd son tour, l'enregistrement redevient modifiable par autrui.
Notre utilisateur en validant son bouton au bout de deux semaines aura un beau
message lui expliquant tout cela car avant de valider l'application vérifiera
qu'il est bien le détenteur du lock et/ou que l'enregistrement n'a pas été
modifié entre temps. J'ai déjà implémenté cela pour une appli web (Php/mySql)
sans trop de souci. Il y a donc un processus qui se charge de "nettoyer" ces
anciens locks.
Le "pseudo lock" peut simplement avoir une durée de vie. Ce délai passé,
l'utilisateur perd son tour, l'enregistrement redevient modifiable par autrui.
Notre utilisateur en validant son bouton au bout de deux semaines aura un beau
message lui expliquant tout cela car avant de valider l'application vérifiera
qu'il est bien le détenteur du lock et/ou que l'enregistrement n'a pas été
modifié entre temps. J'ai déjà implémenté cela pour une appli web (Php/mySql)
sans trop de souci. Il y a donc un processus qui se charge de "nettoyer" ces
anciens locks.
Bonjour,
Merci pour cette réponse. Effectivement un processus qui tourne
continuellement et se charge de libérer les éléments restés "bloqués"
trop longtemps est intéressant.
Cordialement
Jean
Bonjour,
Merci pour cette réponse. Effectivement un processus qui tourne
continuellement et se charge de libérer les éléments restés "bloqués"
trop longtemps est intéressant.
Cordialement
Jean
Bonjour,
Merci pour cette réponse. Effectivement un processus qui tourne
continuellement et se charge de libérer les éléments restés "bloqués"
trop longtemps est intéressant.
Cordialement
Jean
Juanito a écrit :Merci pour cette réponse. Effectivement un processus qui tourne
continuellement et se charge de libérer les éléments restés "bloqués" trop
longtemps est intéressant.
dans ce cas inutile de prendre un SGDR client serveur. Préférez un SGBDR
fichier comme paradox... (je vais faire plaisir à Come....) Cela sera beaucoup
plus facile à implémenter....
Juanito a écrit :
Merci pour cette réponse. Effectivement un processus qui tourne
continuellement et se charge de libérer les éléments restés "bloqués" trop
longtemps est intéressant.
dans ce cas inutile de prendre un SGDR client serveur. Préférez un SGBDR
fichier comme paradox... (je vais faire plaisir à Come....) Cela sera beaucoup
plus facile à implémenter....
Juanito a écrit :Merci pour cette réponse. Effectivement un processus qui tourne
continuellement et se charge de libérer les éléments restés "bloqués" trop
longtemps est intéressant.
dans ce cas inutile de prendre un SGDR client serveur. Préférez un SGBDR
fichier comme paradox... (je vais faire plaisir à Come....) Cela sera beaucoup
plus facile à implémenter....