Problème de blocage en réseau

Le
Réal Phil
Bonjour,

À l'occasion, j'ai un client en réseau qui a le message suivant de
Windev 8 lui indiquant qu'il y a confusion dans la modification d'une
rubrique d'un fichier n'ayant que l'enregistrement no 1.

Le mécanisme de sécurité assisté de l'application a été décla=
nché ;
(j'essai d'aligner du mieux que je peux les prochaines lignes)

Valeurs des rubriques ProchainNoFacture
PromoInstanFactImpl
Lues à l'origine dans le fichier:
161162 79110
Définies par un autre utilisateur:
161163 79111
Vous voulez écrire dans le fichier: 161162
79110
À valider dans le fichier:
161163 79111

2 zones sont concernées

La fiche que vous avez modifiée a également été modifiée en mêm=
e temps
par un autre utilisateur !

J'ai pourtant l'impression qu'il n'y a aucune erreur de logique dans
mon code et que la situation mentionnée ci-dessus ne devrait jamais se
produire.

Voici le code en question;

HMode(HModeMulti) //définit dans l'initialisation du Projet

// Le code lors de l'enregistrement d'une facture
SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
NoFactEnCours=Inf.ProchainNoFacture
SI NoFactEnCours>=999999 ALORS Inf.ProchainNoFacture=1 SINON
Inf.ProchainNoFacture++
HModifie(Inf)
HDébloqueNumEnr(Inf,1)
SINON
Avertissement("Erreur de blocage du fichier Inf.fic")
RETOUR
FIN

// et environ 800 lignes plus bas
SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
Inf.PromoInstanFactImpl++
SI PromoInstantGagnant ALORS Inf.PromoInstantGagnant++
HModifie(Inf)
HDébloqueNumEnr(Inf,1)
FIN

Quelqu'un voit-il une erreur dans ce code ?
Est-ce possible que les blocages de Windev en réseau ne soient pas
fiables ?

Toute suggestion sera appréciée.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
STASZEWSKI André
Le #19646741
Salut Réal !

Je pense que l'erreur survient à chaque passage à 100 000 de NoFactEnCours.
Pour moi Inf.ProchainNoFacture ne passera jamais à 1 mais à 2 au minimum
d'après le code.
Essai de mettre zéro sur cette ligne :
SI NoFactEnCours>™9999 ALORS Inf.ProchainNoFacture=0 SINON
Inf.ProchainNoFacture++
Fais un test de deboggage avec ton code en partant d'un n° de facture à
999999 et regarde la valeur de tes variables.
--
Cordialement,
André STASZEWSKI
(Gratuit) Photo Visu et Cut Data Radars sur
http://pagesperso-orange.fr/mdev/
Pour me contacter, cliquez ici :
http://cerbermail.com/?OT0Wnwyzph

"Réal Phil"
Bonjour,

À l'occasion, j'ai un client en réseau qui a le message suivant de
Windev 8 lui indiquant qu'il y a confusion dans la modification d'une
rubrique d'un fichier n'ayant que l'enregistrement no 1.

Le mécanisme de sécurité assisté de l'application a été déclanché ;
(j'essai d'aligner du mieux que je peux les prochaines lignes)

Valeurs des rubriques ProchainNoFacture
PromoInstanFactImpl
Lues à l'origine dans le fichier:
161162 79110
Définies par un autre utilisateur:
161163 79111
Vous voulez écrire dans le fichier: 161162
79110
À valider dans le fichier:
161163 79111

2 zones sont concernées

La fiche que vous avez modifiée a également été modifiée en même temps
par un autre utilisateur !

J'ai pourtant l'impression qu'il n'y a aucune erreur de logique dans
mon code et que la situation mentionnée ci-dessus ne devrait jamais se
produire.

Voici le code en question;

HMode(HModeMulti) //définit dans l'initialisation du Projet

// Le code lors de l'enregistrement d'une facture
SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
NoFactEnCours=Inf.ProchainNoFacture
SI NoFactEnCours>™9999 ALORS Inf.ProchainNoFacture=1 SINON
Inf.ProchainNoFacture++
HModifie(Inf)
HDébloqueNumEnr(Inf,1)
SINON
Avertissement("Erreur de blocage du fichier Inf.fic")
RETOUR
FIN

// ...et environ 800 lignes plus bas...
SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
Inf.PromoInstanFactImpl++
SI PromoInstantGagnant ALORS Inf.PromoInstantGagnant++
HModifie(Inf)
HDébloqueNumEnr(Inf,1)
FIN

Quelqu'un voit-il une erreur dans ce code ?
Est-ce possible que les blocages de Windev en réseau ne soient pas
fiables ?

Toute suggestion sera appréciée.
Phil
Le #19665431
On 26 juin, 19:05, "STASZEWSKI André"
Salut Réal !

Je pense que l'erreur survient à chaque passage à 100 000 de NoFactEn Cours.
Pour moi Inf.ProchainNoFacture ne passera jamais à 1 mais à 2 au mini mum
d'après le code.
Essai de mettre zéro sur cette ligne :
SI NoFactEnCours>™9999 ALORS Inf.ProchainNoFacture=0 SINON
Inf.ProchainNoFacture++
Fais un test de deboggage avec ton code en partant d'un n° de facture à
999999 et regarde la valeur de tes variables.
--
Cordialement,
André STASZEWSKI
(Gratuit) Photo Visu et Cut Data Radars surhttp://pagesperso-orange.fr/md ev/
Pour me contacter, cliquez ici :http://cerbermail.com/?OT0Wnwyzph

"Réal Phil"
Bonjour,

À l'occasion, j'ai un client en réseau qui a le message suivant de
Windev 8 lui indiquant qu'il y a confusion dans la modification d'une
rubrique d'un fichier n'ayant que l'enregistrement no 1.

Le mécanisme de sécurité assisté de l'application a été déc lanché ;
(j'essai d'aligner du mieux que je peux les prochaines lignes)

Valeurs des rubriques ProchainNoFacture
PromoInstanFactImpl
Lues à l'origine dans le fichier:
161162 79110
Définies par un autre utilisateur:
161163 79111
Vous voulez écrire dans le fichier: 161162
79110
À valider dans le fichier:
161163 79111

2 zones sont concernées

La fiche que vous avez modifiée a également été modifiée en m ême temps
par un autre utilisateur !

J'ai pourtant l'impression qu'il n'y a aucune erreur de logique dans
mon code et que la situation mentionnée ci-dessus ne devrait jamais se
produire.

Voici le code en question;

HMode(HModeMulti) //définit dans l'initialisation du Projet

// Le code lors de l'enregistrement d'une facture
SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
NoFactEnCours=Inf.ProchainNoFacture
SI NoFactEnCours>™9999 ALORS Inf.ProchainNoFacture=1 SINON
Inf.ProchainNoFacture++
HModifie(Inf)
HDébloqueNumEnr(Inf,1)
SINON
Avertissement("Erreur de blocage du fichier Inf.fic")
RETOUR
FIN

// ...et environ 800 lignes plus bas...
SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
Inf.PromoInstanFactImpl++
SI PromoInstantGagnant ALORS Inf.PromoInstantGagnant++
HModifie(Inf)
HDébloqueNumEnr(Inf,1)
FIN

Quelqu'un voit-il une erreur dans ce code ?
Est-ce possible que les blocages de Windev en réseau ne soient pas
fiables ?

Toute suggestion sera appréciée.



Salut André !

Ça fait vraiment plaisir d'avoir de tes nouvelles !
J'ai finalement trouvé la raison du bug il y a seulement quelques
instants. L'erreur était ailleurs dans d'autres modules qui
modifiaient sans méfiance une rubrique dans Inf.fic en même temps que
d'autres postes enregistraient des factures. Du code dans le genre;
Inf.MaRubrique=MaValeur
HModifie(Inf)
... ce qui est mortel en réseau, parce qu'il faut s'assurer de lire
les données avant et de bloquer en même temps.
Le code correct et corrigé dans les autres modules est;
SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
Inf.MaRubrique=MaValeur
HModifie(Inf,1)
HDébloqueNumEnr(Inf,1)
FIN

Bye !
STASZEWSKI André
Le #19665671
Salut Réal.

Content pour toi !
Ca marche ton affaire ?
Ton projet de location as-t-il enfin vu le jour ?
Pour ma part, je viens de fêter 1/2 siècle d'existance (dont 18 ans de WD) !
Qu'est ce que ça passe vite quand même...
A bientôt !
--
Cordialement,
André STASZEWSKI
(Gratuit) Photo Visu et Cut Data Radars sur
http://pagesperso-orange.fr/mdev/
Pour me contacter, cliquez ici :
http://cerbermail.com/?OT0Wnwyzph

"Phil"
On 26 juin, 19:05, "STASZEWSKI André"
Salut Réal !

Je pense que l'erreur survient à chaque passage à 100 000 de
NoFactEnCours.
Pour moi Inf.ProchainNoFacture ne passera jamais à 1 mais à 2 au minimum
d'après le code.
Essai de mettre zéro sur cette ligne :
SI NoFactEnCours>™9999 ALORS Inf.ProchainNoFacture=0 SINON
Inf.ProchainNoFacture++
Fais un test de deboggage avec ton code en partant d'un n° de facture à
999999 et regarde la valeur de tes variables.
--
Cordialement,
André STASZEWSKI
(Gratuit) Photo Visu et Cut Data Radars
surhttp://pagesperso-orange.fr/mdev/
Pour me contacter, cliquez ici :http://cerbermail.com/?OT0Wnwyzph

"Réal Phil"
Bonjour,

À l'occasion, j'ai un client en réseau qui a le message suivant de
Windev 8 lui indiquant qu'il y a confusion dans la modification d'une
rubrique d'un fichier n'ayant que l'enregistrement no 1.

Le mécanisme de sécurité assisté de l'application a été déclanché ;
(j'essai d'aligner du mieux que je peux les prochaines lignes)

Valeurs des rubriques ProchainNoFacture
PromoInstanFactImpl
Lues à l'origine dans le fichier:
161162 79110
Définies par un autre utilisateur:
161163 79111
Vous voulez écrire dans le fichier: 161162
79110
À valider dans le fichier:
161163 79111

2 zones sont concernées

La fiche que vous avez modifiée a également été modifiée en même temps
par un autre utilisateur !

J'ai pourtant l'impression qu'il n'y a aucune erreur de logique dans
mon code et que la situation mentionnée ci-dessus ne devrait jamais se
produire.

Voici le code en question;

HMode(HModeMulti) //définit dans l'initialisation du Projet

// Le code lors de l'enregistrement d'une facture
SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
NoFactEnCours=Inf.ProchainNoFacture
SI NoFactEnCours>™9999 ALORS Inf.ProchainNoFacture=1 SINON
Inf.ProchainNoFacture++
HModifie(Inf)
HDébloqueNumEnr(Inf,1)
SINON
Avertissement("Erreur de blocage du fichier Inf.fic")
RETOUR
FIN

// ...et environ 800 lignes plus bas...
SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
Inf.PromoInstanFactImpl++
SI PromoInstantGagnant ALORS Inf.PromoInstantGagnant++
HModifie(Inf)
HDébloqueNumEnr(Inf,1)
FIN

Quelqu'un voit-il une erreur dans ce code ?
Est-ce possible que les blocages de Windev en réseau ne soient pas
fiables ?

Toute suggestion sera appréciée.



Salut André !

Ça fait vraiment plaisir d'avoir de tes nouvelles !
J'ai finalement trouvé la raison du bug il y a seulement quelques
instants. L'erreur était ailleurs dans d'autres modules qui
modifiaient sans méfiance une rubrique dans Inf.fic en même temps que
d'autres postes enregistraient des factures. Du code dans le genre;
Inf.MaRubrique=MaValeur
HModifie(Inf)
... ce qui est mortel en réseau, parce qu'il faut s'assurer de lire
les données avant et de bloquer en même temps.
Le code correct et corrigé dans les autres modules est;
SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
Inf.MaRubrique=MaValeur
HModifie(Inf,1)
HDébloqueNumEnr(Inf,1)
FIN

Bye !
Phil
Le #19711361
On 29 juin, 16:41, "STASZEWSKI André"
Salut Réal.

Content pour toi !
Ca marche ton affaire ?
Ton projet de location as-t-il enfin vu le jour ?
Pour ma part, je viens de fêter 1/2 siècle d'existance (dont 18 ans d e WD) !
Qu'est ce que ça passe vite quand même...
A bientôt !
--
Cordialement,
André STASZEWSKI
(Gratuit) Photo Visu et Cut Data Radars surhttp://pagesperso-orange.fr/md ev/
Pour me contacter, cliquez ici :http://cerbermail.com/?OT0Wnwyzph

"Phil"
On 26 juin, 19:05, "STASZEWSKI André"


> Salut Réal !

> Je pense que l'erreur survient à chaque passage à 100 000 de
> NoFactEnCours.
> Pour moi Inf.ProchainNoFacture ne passera jamais à 1 mais à 2 au mi nimum
> d'après le code.
> Essai de mettre zéro sur cette ligne :
> SI NoFactEnCours>™9999 ALORS Inf.ProchainNoFacture=0 SINON
> Inf.ProchainNoFacture++
> Fais un test de deboggage avec ton code en partant d'un n° de facture à
> 999999 et regarde la valeur de tes variables.
> --
> Cordialement,
> André STASZEWSKI
> (Gratuit) Photo Visu et Cut Data Radars
> surhttp://pagesperso-orange.fr/mdev/
> Pour me contacter, cliquez ici :http://cerbermail.com/?OT0Wnwyzph

> "Réal Phil" >
> Bonjour,

> À l'occasion, j'ai un client en réseau qui a le message suivant de
> Windev 8 lui indiquant qu'il y a confusion dans la modification d'une
> rubrique d'un fichier n'ayant que l'enregistrement no 1.

> Le mécanisme de sécurité assisté de l'application a été d éclanché ;
> (j'essai d'aligner du mieux que je peux les prochaines lignes)

> Valeurs des rubriques ProchainNoFacture
> PromoInstanFactImpl
> Lues à l'origine dans le fichier:
> 161162 79110
> Définies par un autre utilisateur:
> 161163 79111
> Vous voulez écrire dans le fichier: 161162
> 79110
> À valider dans le fichier:
> 161163 79111

> 2 zones sont concernées

> La fiche que vous avez modifiée a également été modifiée en m ême temps
> par un autre utilisateur !

> J'ai pourtant l'impression qu'il n'y a aucune erreur de logique dans
> mon code et que la situation mentionnée ci-dessus ne devrait jamais s e
> produire.

> Voici le code en question;

> HMode(HModeMulti) //définit dans l'initialisation du Projet

> // Le code lors de l'enregistrement d'une facture
> SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
> NoFactEnCours=Inf.ProchainNoFacture
> SI NoFactEnCours>™9999 ALORS Inf.ProchainNoFacture=1 SINON
> Inf.ProchainNoFacture++
> HModifie(Inf)
> HDébloqueNumEnr(Inf,1)
> SINON
> Avertissement("Erreur de blocage du fichier Inf.fic")
> RETOUR
> FIN

> // ...et environ 800 lignes plus bas...
> SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
> Inf.PromoInstanFactImpl++
> SI PromoInstantGagnant ALORS Inf.PromoInstantGagnant++
> HModifie(Inf)
> HDébloqueNumEnr(Inf,1)
> FIN

> Quelqu'un voit-il une erreur dans ce code ?
> Est-ce possible que les blocages de Windev en réseau ne soient pas
> fiables ?

> Toute suggestion sera appréciée.

Salut André !

Ça fait vraiment plaisir d'avoir de tes nouvelles !
J'ai finalement trouvé la raison du bug il y a seulement quelques
instants. L'erreur était ailleurs dans d'autres modules qui
modifiaient sans méfiance une rubrique dans Inf.fic en même temps que
d'autres postes enregistraient des factures. Du code dans le genre;
Inf.MaRubrique=MaValeur
HModifie(Inf)
... ce qui est mortel en réseau, parce qu'il faut s'assurer de lire
les données avant et de bloquer en même temps.
Le code correct et corrigé dans les autres modules est;
SI HLit(Inf,1,hBlocageLectureÉcriture) ALORS
Inf.MaRubrique=MaValeur
HModifie(Inf,1)
HDébloqueNumEnr(Inf,1)
FIN

Bye !


Je t'envoie un mail personnel.
Bye!
news.online.fr
Le #19712331
Le Tue, 07 Jul 2009 00:06:25 +0200, Phil
On 29 juin, 16:41, "STASZEWSKI André"
Salut Réal.

Content pour toi !




[...]

Bye !


Je t'envoie un mail personnel.
Bye!


Merci ,garder toutes ces ligne inutiles pour dire cela !!!!


--
TT
Phil
Le #19722531
De quelles lignes parles-tu, je n'en vois aucune ici ?
news.online.fr
Le #19722781
Le Wed, 08 Jul 2009 15:49:15 +0200, Phil
De quelles lignes parles-tu, je n'en vois aucune ici ?



Dans le message auquel je répondais , je les ai enlevées... dans le mien.

--
TT
Publicité
Poster une réponse
Anonyme