[WD9] Dysfonctionnement en HF C/S sur la gestion des blocages ?

Emmanuel Haefele a écrit :

Bonjour,

Je constate quelque chose d'étrange en HF C/S et qui n'est pas
reproductible en Classic.

En simplifié voici le code incriminé :

HLitRecherchePremier ( Fichier, Rubrique, Cle, ...
hBlocageEcriture+hGénérique )

si HErreurBlocage() alors
info ( "L'enregistrement est bloqué, accès impossible")
fin

Le nom du fichier est VERROUS, la rubrique est une clé composée texte sur
95 positions. Ma clé est composée de la manière suivante :

Cle est une chaîne = Complète ( sVar1, 20 ) + Complète ( sVar2, 75 )

Le symptôme maintenant :

Lorsque je bloque un enregistrement tous les enregistrements qui se
trouvent avant sont également bloqués (ceux après, aucun problème). Pour
que le symptôme apparaisse il faut aussi que le deuxième poste soit dans
l'application au moment du blocage par le premier poste car sinon le
phénomène ne se produit pas.

Ce code est une migration de 5.5 vers 9, il fonctionnait naturellement
très correctement en 5.5 et en 9 avec HF Classic mais en C/S me pose
ce problème particulier, étrange non ?

Il me semble déjà avoir entendu parler d'un pareil problème mais je ne
retrouve pas où !

Une idée ?


Amicalement,

Emmanuel Haefelé.

Tu fais une recherche générique, est-ce normal ? Il peut alors te
trouver plusieurs enreg correspondant non ?

Bruno

--
Bruno A

suivre ce lien pour répondre :
http://cerbermail.com/?TF4s3h4ejs
;)

"Bruno A" <voir.signature@enbas.fr> a écrit :

Bonjour Bruno,

Tu fais une recherche générique, est-ce normal ? Il peut alors te
trouver plusieurs enreg correspondant non ?

En fait j'ai systématiquement positionné une recherche générique lors de
mes lectures par compatibilité avec la 5.5, tu constateras également que
ma clé est composée et complétée par des blancs et que par conséquent le
hgénérique de doit pas être un soucis.

Mais effectivement j'aurai dû précisé que j'avais fait le test en enlevant
le hgénérique et que la situation restait identique :-(


Amicalement,

Emmanuel Haefelé.

J'ai refait quelques tests de blocages dans mon appli (WD10 37f, C/S),
et d'après le centre de controle je n'ai qu'un enreg de bloqué. Les
blocages se font aussi bien avec Hlitrecherchepremier ou Hlit .

Bruno

Emmanuel Haefele a écrit :

"Bruno A" <voir.signature@enbas.fr> a écrit :

Bonjour Bruno,

Tu fais une recherche générique, est-ce normal ? Il peut alors te
trouver plusieurs enreg correspondant non ?

En fait j'ai systématiquement positionné une recherche générique lors de
mes lectures par compatibilité avec la 5.5, tu constateras également que
ma clé est composée et complétée par des blancs et que par conséquent le
hgénérique de doit pas être un soucis.

Mais effectivement j'aurai dû précisé que j'avais fait le test en enlevant
le hgénérique et que la situation restait identique :-(


Amicalement,

Emmanuel Haefelé.

--
Bruno A

suivre ce lien pour répondre :
http://cerbermail.com/?TF4s3h4ejs
;)

"Bruno A" <voir.signature@enbas.fr> a écrit :

J'ai refait quelques tests de blocages dans mon appli (WD10 37f, C/S),
et d'après le centre de controle je n'ai qu'un enreg de bloqué. Les
blocages se font aussi bien avec Hlitrecherchepremier ou Hlit .

Je n'ai pas l'habitude de HF C/S et je n'avais pas pensé à vérifier ça.
Chez moi aussi il n'y a qu'un enregistrement de bloqué au niveau du centre
de contrôle.

Par contre je viens de faire d'autres tests et je constate qu'avec une
exécution pas à pas au débugger là aussi ça ne pose pas de problème. Ce
blocage est effectué à l'ouverture d'une fenetre fille, peut-être une
piste à suivre ...


Amicalement,

Emmanuel Haefelé.

"Emmanuel Haefele" <e.haefele@windasso.org> :

Bonjour,

Je n'ai pas l'habitude de HF C/S et je n'avais pas pensé à vérifier ça.
Chez moi aussi il n'y a qu'un enregistrement de bloqué au niveau du
centre de contrôle.

J'ai encore fait quelques tests et finalement j'ai compris précisément ce
qui se passe et mon interprétation du problème n'était pas tout à fait
exact. Ceci dit il y a bien une différence de fonctionnement entre HF C/S
et HF Classic au niveau du compte-rendu de blocage. A titre d'info voici
ce qui se produit exactement.

J'ai un fichier avec une clé composée (texte) qui est clé unique,
j'imagine que ça doit se produire également sur des clés simples.

Dans ce fichier je n'ai qu'un seul enregistrement qui lui-même est bloqué,
supposons une clé unique ayant pour valeur "Z". Le problème se situe
lorsqu'on tente de vérifier l'existence et le blocage d'une clé
inférieure, de la manière suivante par exemple :

sVar2 est une chaine = ""
Cle est une chaîne = Complète ( "A", 20 ) + Complète ( sVar2, 75 )
HLitRecherchePremier ( Fic, Rub, Cle, hBlocageEcriture )

En HF Classic :

L'enregistrement n'est pas trouvé (normal il n'existe pas) mais un
positionnement est fait sur le suivant, le compte-rendu de blocage
(HerreurBlocage) = Faux

En HF C/S :

L'enregistrement n'est pas trouvé (toujours normal) mais cette fois-ci
aucun positionnement sur l'enregistrement suivant par contre le
compte-rendu de blocage (HerreurBlocage) = Vrai !

Conclusion et sauf à me tromper en HF C/S, le compte-rendu de blocage est
erroné, l'un des moyens de contourner le problème est de faire une lecture
non bloquante de l'enregistrement puis de faire un HLit avec blocage sur
la base de la variable HNumenr.

J'ai cherché longtemps, en espérant que ça puisse être utile d'autres ...

C'est du WD9, je serais quand même curieux de savoir quel est le résultat
en WD10. Sans être méchant à mon avis le même mais je peux me tromper ...


Amicalement,

Emmanuel Haefelé.

Bonjour,

1) Ne devrais-tu pas d'abord tester si la lecture a été faite par un If ?
Moi, je teste d'abord si la lecture a abouti et, si oui, je me demande
ensuite si l'enregistrement est déjà bloqué parceque cela ne me semble pas
"anormal" que les autres booleens (bloqué, endehors, etc..) ne soient pas
mis à jour si la lecture n'a pas abouti. (a moins que, pour nous donner
l'exemple, tu as simplifié le code)

2) Puisque ta clé composée est "sans doublons", pourquoi un
HLitRecherchePremier et pas simplement un hLitRecherche (à l'identique
puisque tu as fait des complete() ).

Je ne dis pas que d'après la doc ton code est erroné (je ne l'ai pas lue
puisque je n'utilise pas les litRecherchePremier etc..), mais je suis
presque sur que ça devrait fonctionner avec les 2 points que j'avance.

Espérant avoir fait avancer le truc,

Victor




"Emmanuel Haefele" <e.haefele@windasso.org> a écrit dans le message de news:
443238ed$0$21269$8fcfb975@news.wanadoo.fr...

"Emmanuel Haefele" <e.haefele@windasso.org> :

Bonjour,

Je n'ai pas l'habitude de HF C/S et je n'avais pas pensé à vérifier ça.
Chez moi aussi il n'y a qu'un enregistrement de bloqué au niveau du
centre de contrôle.

J'ai encore fait quelques tests et finalement j'ai compris précisément ce
qui se passe et mon interprétation du problème n'était pas tout à fait
exact. Ceci dit il y a bien une différence de fonctionnement entre HF C/S
et HF Classic au niveau du compte-rendu de blocage. A titre d'info voici
ce qui se produit exactement.

J'ai un fichier avec une clé composée (texte) qui est clé unique,
j'imagine que ça doit se produire également sur des clés simples.

Dans ce fichier je n'ai qu'un seul enregistrement qui lui-même est bloqué,
supposons une clé unique ayant pour valeur "Z". Le problème se situe
lorsqu'on tente de vérifier l'existence et le blocage d'une clé
inférieure, de la manière suivante par exemple :

sVar2 est une chaine = ""
Cle est une chaîne = Complète ( "A", 20 ) + Complète ( sVar2, 75 )
HLitRecherchePremier ( Fic, Rub, Cle, hBlocageEcriture )

En HF Classic :

L'enregistrement n'est pas trouvé (normal il n'existe pas) mais un
positionnement est fait sur le suivant, le compte-rendu de blocage
(HerreurBlocage) = Faux

En HF C/S :

L'enregistrement n'est pas trouvé (toujours normal) mais cette fois-ci
aucun positionnement sur l'enregistrement suivant par contre le
compte-rendu de blocage (HerreurBlocage) = Vrai !

Conclusion et sauf à me tromper en HF C/S, le compte-rendu de blocage est
erroné, l'un des moyens de contourner le problème est de faire une lecture
non bloquante de l'enregistrement puis de faire un HLit avec blocage sur
la base de la variable HNumenr.

J'ai cherché longtemps, en espérant que ça puisse être utile d'autres ...

C'est du WD9, je serais quand même curieux de savoir quel est le résultat
en WD10. Sans être méchant à mon avis le même mais je peux me tromper ...


Amicalement,

Emmanuel Haefelé.

Emmanuel Haefele wrote:

sVar2 est une chaine = ""
Cle est une chaîne = Complète ( "A", 20 ) + Complète ( sVar2, 75 )
HLitRecherchePremier ( Fic, Rub, Cle, hBlocageEcriture )

En HF Classic :

L'enregistrement n'est pas trouvé (normal il n'existe pas) mais un
positionnement est fait sur le suivant, le compte-rendu de blocage
(HerreurBlocage) = Faux

En HF C/S :

L'enregistrement n'est pas trouvé (toujours normal) mais cette fois-ci
aucun positionnement sur l'enregistrement suivant par contre le
compte-rendu de blocage (HerreurBlocage) = Vrai !

Bonjour Emmanuel,

Ca touche à un problème de base de Windev : à mon avis les deux
comportements sont faux. Ils ont introduit HLitRecherchePREMIER pour une
recherche identique, tandis que sans "premier" le défaut est générique.
MAIS le curseur se comporte comme dans une recherche générique,
lorsqu'il ne retrouve pas une valeur, il se déplace sur l'enregistrement
suivant. Or, je ne connais pas d'autre langage ou un curseur se déplace
lorsque une recherche à l'identique ne trouve rien. En plus, il y a le
problème d'une double fonction: recherche et blocage. Dans certains cas
je ne m'intéresse pas pourquoi ça ne fonctionne pas, alors je fais
simplement SI hLit.. ALORS... Si je m'y intéresse, alors je teste en
plus hTrouve ou je fais d'abord hLitRecherche.. suivi par HBloqueNumEnr.
Alors, par hasard j'évite ton problème.

Dans le cas de HF C/S, si le comportement est ainsi, c'est faux puisque
l'enregistrement en cours n'est pas celui recherché.

Salutations
Mat

"mat" <NoSPAM-mnobs@windasso.org> a écrit:

MAIS le curseur se comporte comme dans une recherche générique,
lorsqu'il ne retrouve pas une valeur, il se déplace sur l'enregistrement
suivant. Or, je ne connais pas d'autre langage ou un curseur se déplace
lorsque une recherche à l'identique ne trouve rien.

Ca m'a effectivement surpris aussi

En plus, il y a le
problème d'une double fonction: recherche et blocage. Dans certains cas
je ne m'intéresse pas pourquoi ça ne fonctionne pas, alors je fais
simplement SI hLit.. ALORS... Si je m'y intéresse, alors je teste en
plus hTrouve ou je fais d'abord hLitRecherche.. suivi par HBloqueNumEnr.
Alors, par hasard j'évite ton problème.

Comme je l'ai dit à Victor dans ma deuxième réponse le HLit Préliminaire
ne me parait pas très très approprié et finalement je pense que le plus
performant doit être de tester HTrouve en plus. Personnellement je pense
que ça alourdi le code mais bon pourquoi pas ...

Dans le cas de HF C/S, si le comportement est ainsi, c'est faux puisque
l'enregistrement en cours n'est pas celui recherché.

Là aussi d'accord avec toi.


Amicalement,

Emmanuel Haefelé.

"VPSoft" <vpsoft@wanadoo.fr> a écrit :

Bonjour Victor,

1) Ne devrais-tu pas d'abord tester si la lecture a été faite par un If
Moi, je teste d'abord si la lecture a abouti et, si oui, je me demande
ensuite si l'enregistrement est déjà bloqué parceque cela ne me semble
pas "anormal" que les autres booleens (bloqué, endehors, etc..) ne
soient pas mis à jour si la lecture n'a pas abouti. (a moins que, pour
nous donner l'exemple, tu as simplifié le code)

Normal pas normal, je ne sais pas exactement. Ce que je sais c'est que
lorsque je fais le test, avant ma fonction HLit, HErreurBlocage = faux et
qu'après (alors qu'il ne trouve pas l'enregistrement) HErreurBlocage vrai. Donc tu seras d'accord avec moi que le booleen a changé et
personnellement ce que je constate aussi c'est que ce comportement est
apparu avec HF C/S.

Concernant ta méthode qui consiste à lire l'enregistrement avant, je n'en
suis pas très partisan non plus car dans la fraction de seconde qui suit
ton HLit l'enregistrement peut très bien avoir été supprimé par un autre
poste. Donc pour moi le comportement correct sur HErreurBlocage serait :

Si je lis l'enregistrement, qu'il existe et qu'il est déjà bloqué, que
WinDev me rende HErreurBlocage à Vrai et que dans tout les autres cas (que
l'enregistrement existe ou pas) que HErreurBlocage me rende Faux. Pour moi
c'est ce qui serait le plus logique maintenant pour pcsoft sans doute pas
puisqu'ils imposent apparemment dans ce cas précis un test supplémentaire
sur HTrouve.

2) Puisque ta clé composée est "sans doublons", pourquoi un
HLitRecherchePremier et pas simplement un hLitRecherche (à l'identique
puisque tu as fait des complete() ).

Le problème est identique avec un HLitRecherche, je viens de faire le test
mais ceci dit je suis d'accord avec toi.


Amicalement,

Emmanuel Haefelé.

Bonsoir Emmanuel,

Normal pas normal, je ne sais pas exactement. Ce que je sais c'est que
lorsque je fais le test, avant ma fonction HLit, HErreurBlocage = faux et
qu'après (alors qu'il ne trouve pas l'enregistrement) HErreurBlocage > vrai. Donc tu seras d'accord avec moi que le booleen a changé

Tout à fait d'accord

personnellement ce que je constate aussi c'est que ce comportement est
apparu avec HF C/S.

La, c'est vrai que si c'est bien le cas, c'est "inquiétant"

Concernant ta méthode qui consiste à lire l'enregistrement avant, je n'en
suis pas très partisan non plus car dans la fraction de seconde qui suit
ton HLit l'enregistrement peut très bien avoir été supprimé par un autre
poste.

Pour être précis, lorsque je dois modifier ou supprimer (l'utilisateur
clique sur bouton 'Modif' ou 'Supprime' par exemple), je refais un
hLitRechercheBloque => je vérifie que c'est toujours la, je bloque pour
qu'un autre user ne puisse pas modifier ou supprimer, sans oublier de
débloquer sur le bouton 'Annuler')

Donc pour moi le comportement correct sur HErreurBlocage serait :
Si je lis l'enregistrement, qu'il existe et qu'il est déjà bloqué, que
WinDev me rende HErreurBlocage à Vrai et que dans tout les autres cas (que
l'enregistrement existe ou pas) que HErreurBlocage me rende Faux. Pour moi
c'est ce qui serait le plus logique maintenant pour pcsoft sans doute pas
puisqu'ils imposent apparemment dans ce cas précis un test supplémentaire
sur HTrouve.

Sans vouloir te contredire, tu te bases sur le fait que tu es certain que
ton enregistrement existe.
Si tu te bases seulement sur le résultat du blocage, tu ne sais pas si c'est
à faux parceque ça n'existe pas ou si c'est parceque c'est déjà bloqué par
qq d'autre.
Je fais en fait comme le dit 'MAT' plus bas : j'utilise une classe qui me
renvoie vrai ou faux sur les lectures si trouvé ou pas, vrai ou faux sur les
LitPremier et Dernier si Fin fichier, etc...et selon le cas je teste si déjà
bloqué (issu de la classe de Romain PETIT sur le site de l'asso. Merci à
lui)

A+

Victor