Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Problème de blocage en réseau

7 réponses
Avatar
Réal Phil
Bonjour,

=C0 l'occasion, j'ai un client en r=E9seau 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=E9canisme de s=E9curit=E9 assist=E9 de l'application a =E9t=E9 d=E9cla=
nch=E9 ;
(j'essai d'aligner du mieux que je peux les prochaines lignes)

Valeurs des rubriques ProchainNoFacture
PromoInstanFactImpl
Lues =E0 l'origine dans le fichier:
161162 79110
D=E9finies par un autre utilisateur:
161163 79111
Vous voulez =E9crire dans le fichier: 161162
79110
=C0 valider dans le fichier:
161163 79111

2 zones sont concern=E9es

La fiche que vous avez modifi=E9e a =E9galement =E9t=E9 modifi=E9e en m=EAm=
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=E9e ci-dessus ne devrait jamais se
produire.

Voici le code en question;

HMode(HModeMulti) //d=E9finit dans l'initialisation du Projet

// Le code lors de l'enregistrement d'une facture
SI HLit(Inf,1,hBlocageLecture=C9criture) ALORS
NoFactEnCours=3DInf.ProchainNoFacture
SI NoFactEnCours>=3D999999 ALORS Inf.ProchainNoFacture=3D1 SINON
Inf.ProchainNoFacture++
HModifie(Inf)
HD=E9bloqueNumEnr(Inf,1)
SINON
Avertissement("Erreur de blocage du fichier Inf.fic")
RETOUR
FIN

// ...et environ 800 lignes plus bas...
SI HLit(Inf,1,hBlocageLecture=C9criture) ALORS
Inf.PromoInstanFactImpl++
SI PromoInstantGagnant ALORS Inf.PromoInstantGagnant++
HModifie(Inf)
HD=E9bloqueNumEnr(Inf,1)
FIN

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

Toute suggestion sera appr=E9ci=E9e.

7 réponses

Avatar
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 sur
http://pagesperso-orange.fr/mdev/
Pour me contacter, cliquez ici :
http://cerbermail.com/?OT0Wnwyzph

"Réal Phil" a écrit dans le message de news:

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.
Avatar
Phil
On 26 juin, 19:05, "STASZEWSKI André" wrote:
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" a écrit dans le message de news:

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 !
Avatar
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 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" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://cerbermail.com/?OT0Wnwyzph

"Phil" a écrit dans le message de news:

On 26 juin, 19:05, "STASZEWSKI André" wrote:
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" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://cerbermail.com/?OT0Wnwyzph

"Réal Phil" a écrit dans le message de news:

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 !
Avatar
Phil
On 29 juin, 16:41, "STASZEWSKI André" wrote:
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" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://cerbermail.com/?OT0Wnwyzph

"Phil" a écrit dans le message de news:

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



> 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" target="_blank" class="text-blue hover:opacity-90 " style="word-break: break-all;" rel="noopener nofollow">http://cerbermail.com/?OT0Wnwyzph

> "Réal Phil" a écrit dans le message de news:
>
> 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!
Avatar
news.online.fr
Le Tue, 07 Jul 2009 00:06:25 +0200, Phil a écrit:

On 29 juin, 16:41, "STASZEWSKI André" wrote:
Salut Réal.

Content pour toi !




[...]

Bye !


Je t'envoie un mail personnel.
Bye!


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


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

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