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

[WD10-WD14] HAjoute dans un fichier : une rubrique passe à 0 sans raison.

12 réponses
Avatar
Fredo
Bonjour,

Dans une procédure de mise à jour de fichiers, j'écris dans 2 fichiers à
la suite de la façon suivante :

MaCle est un entier = xxxx

MonFichier1.Cle = MaCle
...
hAjoute(MonFichier1)


Monfichier2.Cle = Macle
Monfichier2.Valeur1 = MaValeur1
Monfichier2.Valeur2 = MaValeur2
hAjoute(MonFichier2)


Entre le hajoute du fichier1 et celui du fichier2, il n'y a aucun
changement de valeur de MaCle, pourtant, de temps en temps, la rubrique
Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la bonne
valeur)

Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonne
valeur et que seule la rubrique MonFichier2.Cle est erronée.

Etant donnée que le lien entre les deux fichiers est bien entendu MaCle,
vous imaginez les problèmes de cohérence.

Le pire du pire c'est que le problème est aléatoire, sur du monoposte et
que les PC sur lesquels le problème survient sont tous ondulés. Le
problème est apparu en version 10 et en version 14.

La variable MaCle est une variable locale à la procédure.

Pour l'instant, je vais essayer de relire le dernier enregistrement
Fichier2 ecrit et tester la validité de Monfichier2.cle = Macle, mais
c'est quand même un peu flippant de ne pas pouvoir se fier à 100% à un
hajoute.

Si vous avez une piste ?

Merci d'avance.

Fred.

10 réponses

1 2
Avatar
VPSoft
Bonsoir,
Je suppose que tu n'as pas donné tout le code, donc, en vrac, quelques
pistes :
- hRaz conditionnel entre l'affectation et le hAjoute ?
- EcranVersFichier '' ''' '' ""
- dépassement de capacité de la variable
- clé alpha recevant la valeur de l'entier pas assez grande ?
- "de temps en temps" vraiment ou alors tous les 127ou les 32767 fois ?

Essaies avec : Monfichier2.Cle = MonFichier1.Cle

Espérant avoir aidé,

Victor


"Fredo" a écrit dans le message de news:
4cb3240d$0$5408$
Bonjour,

Dans une procédure de mise à jour de fichiers, j'écris dans 2 fichiers à
la suite de la façon suivante :

MaCle est un entier = xxxx

MonFichier1.Cle = MaCle
...
hAjoute(MonFichier1)


Monfichier2.Cle = Macle
Monfichier2.Valeur1 = MaValeur1
Monfichier2.Valeur2 = MaValeur2
hAjoute(MonFichier2)


Entre le hajoute du fichier1 et celui du fichier2, il n'y a aucun
changement de valeur de MaCle, pourtant, de temps en temps, la rubrique
Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la bonne
valeur)

Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonne
valeur et que seule la rubrique MonFichier2.Cle est erronée.

Etant donnée que le lien entre les deux fichiers est bien entendu MaCle,
vous imaginez les problèmes de cohérence.

Le pire du pire c'est que le problème est aléatoire, sur du monoposte et
que les PC sur lesquels le problème survient sont tous ondulés. Le
problème est apparu en version 10 et en version 14.

La variable MaCle est une variable locale à la procédure.

Pour l'instant, je vais essayer de relire le dernier enregistrement
Fichier2 ecrit et tester la validité de Monfichier2.cle = Macle, mais
c'est quand même un peu flippant de ne pas pouvoir se fier à 100% à un
hajoute.

Si vous avez une piste ?

Merci d'avance.

Fred.
Avatar
Fredo
Le 11/10/2010 20:53, VPSoft a écrit :
Bonsoir,
Je suppose que tu n'as pas donné tout le code, donc, en vrac, quelques
pistes :
- hRaz conditionnel entre l'affectation et le hAjoute ?
- EcranVersFichier '' ''' '' ""
- dépassement de capacité de la variable
- clé alpha recevant la valeur de l'entier pas assez grande ?
- "de temps en temps" vraiment ou alors tous les 127ou les 32767 fois ?

Essaies avec : Monfichier2.Cle = MonFichier1.Cle

Espérant avoir aidé,

Victor


"Fredo" a écrit dans le message de news:
4cb3240d$0$5408$
Bonjour,

Dans une procédure de mise à jour de fichiers, j'écris dans 2 fichiers à
la suite de la façon suivante :

MaCle est un entier = xxxx

MonFichier1.Cle = MaCle
...
hAjoute(MonFichier1)


Monfichier2.Cle = Macle
Monfichier2.Valeur1 = MaValeur1
Monfichier2.Valeur2 = MaValeur2
hAjoute(MonFichier2)


Entre le hajoute du fichier1 et celui du fichier2, il n'y a aucun
changement de valeur de MaCle, pourtant, de temps en temps, la rubrique
Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la bonne
valeur)

Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonne
valeur et que seule la rubrique MonFichier2.Cle est erronée.

Etant donnée que le lien entre les deux fichiers est bien entendu MaCle,
vous imaginez les problèmes de cohérence.

Le pire du pire c'est que le problème est aléatoire, sur du monoposte et
que les PC sur lesquels le problème survient sont tous ondulés. Le
problème est apparu en version 10 et en version 14.

La variable MaCle est une variable locale à la procédure.

Pour l'instant, je vais essayer de relire le dernier enregistrement
Fichier2 ecrit et tester la validité de Monfichier2.cle = Macle, mais
c'est quand même un peu flippant de ne pas pouvoir se fier à 100% à un
hajoute.

Si vous avez une piste ?

Merci d'avance.

Fred.








Bonjour,

Malheureusement, j'ai donné tout le code, le hraz est AVANT
l'affectation, il n'y a pas d'écranversfichier, la clé n'est pas alpha
(et elle est correctement affectée pour le 1er fichier).

Le de temps en temps c'est une proportion de 3 ou 4 fois sur un mois
avec 800 à 900 enregistrements par jour, donc c'est très faible (
environ une fois sur 6000 et uniquement chez deux clients sur 5000) ...
mais sur une application de facturation c'est brouillon lorsque l'on
perd le lien entre une facture et son règlement.

Merci en tout cas pour votre réponse.

Fred.
Avatar
VPSoft
"Fredo" a écrit dans le message de news:
4cb408ee$0$7676$


Le 11/10/2010 20:53, VPSoft a écrit :
Bonsoir,
Je suppose que tu n'as pas donné tout le code, donc, en vrac, quelques
pistes :
- hRaz conditionnel entre l'affectation et le hAjoute ?
- EcranVersFichier '' ''' '' ""
- dépassement de capacité de la variable
- clé alpha recevant la valeur de l'entier pas assez grande ?
- "de temps en temps" vraiment ou alors tous les 127ou les 32767 fois ?

Essaies avec : Monfichier2.Cle = MonFichier1.Cle

Espérant avoir aidé,

Victor


"Fredo" a écrit dans le message de news:
4cb3240d$0$5408$
Bonjour,

Dans une procédure de mise à jour de fichiers, j'écris dans 2 fichiers à
la suite de la façon suivante :

MaCle est un entier = xxxx

MonFichier1.Cle = MaCle
...
hAjoute(MonFichier1)


Monfichier2.Cle = Macle
Monfichier2.Valeur1 = MaValeur1
Monfichier2.Valeur2 = MaValeur2
hAjoute(MonFichier2)


Entre le hajoute du fichier1 et celui du fichier2, il n'y a aucun
changement de valeur de MaCle, pourtant, de temps en temps, la rubrique
Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la bonne
valeur)

Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonne
valeur et que seule la rubrique MonFichier2.Cle est erronée.

Etant donnée que le lien entre les deux fichiers est bien entendu MaCle,
vous imaginez les problèmes de cohérence.

Le pire du pire c'est que le problème est aléatoire, sur du monoposte et
que les PC sur lesquels le problème survient sont tous ondulés. Le
problème est apparu en version 10 et en version 14.

La variable MaCle est une variable locale à la procédure.

Pour l'instant, je vais essayer de relire le dernier enregistrement
Fichier2 ecrit et tester la validité de Monfichier2.cle = Macle, mais
c'est quand même un peu flippant de ne pas pouvoir se fier à 100% à un
hajoute.

Si vous avez une piste ?

Merci d'avance.

Fred.








Bonjour,

Malheureusement, j'ai donné tout le code, le hraz est AVANT l'affectation,
il n'y a pas d'écranversfichier, la clé n'est pas alpha (et elle est
correctement affectée pour le 1er fichier).

Le de temps en temps c'est une proportion de 3 ou 4 fois sur un mois avec
800 à 900 enregistrements par jour, donc c'est très faible ( environ une
fois sur 6000 et uniquement chez deux clients sur 5000) ... mais sur une
application de facturation c'est brouillon lorsque l'on perd le lien entre
une facture et son règlement.

Merci en tout cas pour votre réponse.

Fred.




Bonjour,

Je suis têtu :-)

MaCle est un entier = xxxx






je suppose que ce xxxx est une variable. Elle est passée en paramètre dans
la procédure, comme par exemple :
Appel de la procédure : P_Maj(NumeroFact)
La procédure : Procedure P_Maj(_NumFact)

Si oui, entre
hAjoute(MonFichier1)






ET
Monfichier2.Cle = Macle







il n'y a vraiment rien ? pas d'appel à une autre procédure qui risque, dans
certains cas particuliers, de toucher à _NumFact ou NumeroFact ? Si on
touche à NumeroFact, _NumFact est affecté par ce changement, d'ou ma
suggestion de faire plutôt "Monfichier2.Cle = MonFichier1.Cle"

Victor
Avatar
Fredo
Le 12/10/2010 18:02, VPSoft a écrit :
"Fredo" a écrit dans le message de news:
4cb408ee$0$7676$


Le 11/10/2010 20:53, VPSoft a écrit :
Bonsoir,
Je suppose que tu n'as pas donné tout le code, donc, en vrac, quelques
pistes :
- hRaz conditionnel entre l'affectation et le hAjoute ?
- EcranVersFichier '' ''' '' ""
- dépassement de capacité de la variable
- clé alpha recevant la valeur de l'entier pas assez grande ?
- "de temps en temps" vraiment ou alors tous les 127ou les 32767 fois ?

Essaies avec : Monfichier2.Cle = MonFichier1.Cle

Espérant avoir aidé,

Victor


"Fredo" a écrit dans le message de news:
4cb3240d$0$5408$
Bonjour,

Dans une procédure de mise à jour de fichiers, j'écris dans 2 fichiers à
la suite de la façon suivante :

MaCle est un entier = xxxx

MonFichier1.Cle = MaCle
...
hAjoute(MonFichier1)


Monfichier2.Cle = Macle
Monfichier2.Valeur1 = MaValeur1
Monfichier2.Valeur2 = MaValeur2
hAjoute(MonFichier2)


Entre le hajoute du fichier1 et celui du fichier2, il n'y a aucun
changement de valeur de MaCle, pourtant, de temps en temps, la rubrique
Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la bonne
valeur)

Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonne
valeur et que seule la rubrique MonFichier2.Cle est erronée.

Etant donnée que le lien entre les deux fichiers est bien entendu MaCle,
vous imaginez les problèmes de cohérence.

Le pire du pire c'est que le problème est aléatoire, sur du monoposte et
que les PC sur lesquels le problème survient sont tous ondulés. Le
problème est apparu en version 10 et en version 14.

La variable MaCle est une variable locale à la procédure.

Pour l'instant, je vais essayer de relire le dernier enregistrement
Fichier2 ecrit et tester la validité de Monfichier2.cle = Macle, mais
c'est quand même un peu flippant de ne pas pouvoir se fier à 100% à un
hajoute.

Si vous avez une piste ?

Merci d'avance.

Fred.








Bonjour,

Malheureusement, j'ai donné tout le code, le hraz est AVANT l'affectation,
il n'y a pas d'écranversfichier, la clé n'est pas alpha (et elle est
correctement affectée pour le 1er fichier).

Le de temps en temps c'est une proportion de 3 ou 4 fois sur un mois avec
800 à 900 enregistrements par jour, donc c'est très faible ( environ une
fois sur 6000 et uniquement chez deux clients sur 5000) ... mais sur une
application de facturation c'est brouillon lorsque l'on perd le lien entre
une facture et son règlement.

Merci en tout cas pour votre réponse.

Fred.




Bonjour,

Je suis têtu :-)

MaCle est un entier = xxxx






je suppose que ce xxxx est une variable. Elle est passée en paramètre dans
la procédure, comme par exemple :
Appel de la procédure : P_Maj(NumeroFact)
La procédure : Procedure P_Maj(_NumFact)

Si oui, entre
hAjoute(MonFichier1)






ET
Monfichier2.Cle = Macle







il n'y a vraiment rien ? pas d'appel à une autre procédure qui risque, dans
certains cas particuliers, de toucher à _NumFact ou NumeroFact ? Si on
touche à NumeroFact, _NumFact est affecté par ce changement, d'ou ma
suggestion de faire plutôt "Monfichier2.Cle = MonFichier1.Cle"

Victor










Bonjour,


Effectivement, XXXX est une variable du type Procedure TrucMuche(pCle
est un entier)

La procédure est appelée de la façon suivante :

lCle est un entier
hlitdernier(MonFichier,MaCle)
lCle = monfichier.macle+1

TrucMuche(lCle)

et depuis j'ai même poussé le vice à mettre Procedure TrucMuche(local
pCle est un entier) en plus de la réaffectation de pCle dans une
variable locale à TrucMuche ...

Et j'ai bien contrôlé (plusieurs fois, ainsi que mes collègues) que la
variable local à TrucMuche n'avait pas d'affectation.

Malgré tout ça, j'ai encore des enregistrements avec cette rubrique qui
passe à 0.

Je pense qu'il doit y avoir quelque chose de particulier chez le client
car j'ai généré (à l'aide d'un automate) plus de 10.000 enregistrements
sur 4 système différents et je n'ai pas réussi à reproduire le phénomène
chez nous.

Fred
Avatar
VPSoft
"Fredo" a écrit dans le message de news:
4cb6d7bf$0$7694$
Le 12/10/2010 18:02, VPSoft a écrit :
"Fredo" a écrit dans le message de news:
4cb408ee$0$7676$


Le 11/10/2010 20:53, VPSoft a écrit :
Bonsoir,
Je suppose que tu n'as pas donné tout le code, donc, en vrac, quelques
pistes :
- hRaz conditionnel entre l'affectation et le hAjoute ?
- EcranVersFichier '' ''' '' ""
- dépassement de capacité de la variable
- clé alpha recevant la valeur de l'entier pas assez grande ?
- "de temps en temps" vraiment ou alors tous les 127ou les 32767 fois ?

Essaies avec : Monfichier2.Cle = MonFichier1.Cle

Espérant avoir aidé,

Victor


"Fredo" a écrit dans le message de news:
4cb3240d$0$5408$
Bonjour,

Dans une procédure de mise à jour de fichiers, j'écris dans 2 fichiers
à
la suite de la façon suivante :

MaCle est un entier = xxxx

MonFichier1.Cle = MaCle
...
hAjoute(MonFichier1)


Monfichier2.Cle = Macle
Monfichier2.Valeur1 = MaValeur1
Monfichier2.Valeur2 = MaValeur2
hAjoute(MonFichier2)


Entre le hajoute du fichier1 et celui du fichier2, il n'y a aucun
changement de valeur de MaCle, pourtant, de temps en temps, la
rubrique
Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la
bonne
valeur)

Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonne
valeur et que seule la rubrique MonFichier2.Cle est erronée.

Etant donnée que le lien entre les deux fichiers est bien entendu
MaCle,
vous imaginez les problèmes de cohérence.

Le pire du pire c'est que le problème est aléatoire, sur du monoposte
et
que les PC sur lesquels le problème survient sont tous ondulés. Le
problème est apparu en version 10 et en version 14.

La variable MaCle est une variable locale à la procédure.

Pour l'instant, je vais essayer de relire le dernier enregistrement
Fichier2 ecrit et tester la validité de Monfichier2.cle = Macle, mais
c'est quand même un peu flippant de ne pas pouvoir se fier à 100% à un
hajoute.

Si vous avez une piste ?

Merci d'avance.

Fred.








Bonjour,

Malheureusement, j'ai donné tout le code, le hraz est AVANT
l'affectation,
il n'y a pas d'écranversfichier, la clé n'est pas alpha (et elle est
correctement affectée pour le 1er fichier).

Le de temps en temps c'est une proportion de 3 ou 4 fois sur un mois
avec
800 à 900 enregistrements par jour, donc c'est très faible ( environ une
fois sur 6000 et uniquement chez deux clients sur 5000) ... mais sur une
application de facturation c'est brouillon lorsque l'on perd le lien
entre
une facture et son règlement.

Merci en tout cas pour votre réponse.

Fred.




Bonjour,

Je suis têtu :-)

MaCle est un entier = xxxx






je suppose que ce xxxx est une variable. Elle est passée en paramètre
dans
la procédure, comme par exemple :
Appel de la procédure : P_Maj(NumeroFact)
La procédure : Procedure P_Maj(_NumFact)

Si oui, entre
hAjoute(MonFichier1)






ET
Monfichier2.Cle = Macle







il n'y a vraiment rien ? pas d'appel à une autre procédure qui risque,
dans
certains cas particuliers, de toucher à _NumFact ou NumeroFact ? Si on
touche à NumeroFact, _NumFact est affecté par ce changement, d'ou ma
suggestion de faire plutôt "Monfichier2.Cle = MonFichier1.Cle"

Victor










Bonjour,


Effectivement, XXXX est une variable du type Procedure TrucMuche(pCle est
un entier)

La procédure est appelée de la façon suivante :

lCle est un entier
hlitdernier(MonFichier,MaCle)
lCle = monfichier.macle+1

TrucMuche(lCle)

et depuis j'ai même poussé le vice à mettre Procedure TrucMuche(local pCle
est un entier) en plus de la réaffectation de pCle dans une variable
locale à TrucMuche ...

Et j'ai bien contrôlé (plusieurs fois, ainsi que mes collègues) que la
variable local à TrucMuche n'avait pas d'affectation.

Malgré tout ça, j'ai encore des enregistrements avec cette rubrique qui
passe à 0.

Je pense qu'il doit y avoir quelque chose de particulier chez le client
car j'ai généré (à l'aide d'un automate) plus de 10.000 enregistrements
sur 4 système différents et je n'ai pas réussi à reproduire le phénomène
chez nous.

Fred




Bonjour,

Je ne vois plus que trois possibilités :
1) Doublons : un autre poste (ou en monoposte l'utilisateur lance le prog 2
fois) crée un enregistrement entre-temps. Il faudrait vérifier si tu as un
traitement suite à erreur qui ferait que tu crée l'enregistrement avec une
clé à 0
2) Ta clé n'est pas vraiment à zéro. Tu le vois comment ? Affichage dans ta
fenêtre ou par WdMap ? Est-elle vraiment à zéro JUSTE APRES près le hAjoute
?

3) un autre traitement met à zéro ta clé. Yaurait pas un Trigger qui traîne
?

Suggestion : comme ce n'est pas reproductible, mets donc à jour un mouchard
juste après le hAjoute (fichier txt avec datesys ; heuresys ; WinUser ;
pCle ; Monfichier2.Cle )

Victor
Avatar
Fredo
Le 14/10/2010 18:14, VPSoft a écrit :
"Fredo" a écrit dans le message de news:
4cb6d7bf$0$7694$
Le 12/10/2010 18:02, VPSoft a écrit :
"Fredo" a écrit dans le message de news:
4cb408ee$0$7676$


Le 11/10/2010 20:53, VPSoft a écrit :
Bonsoir,
Je suppose que tu n'as pas donné tout le code, donc, en vrac, quelques
pistes :
- hRaz conditionnel entre l'affectation et le hAjoute ?
- EcranVersFichier '' ''' '' ""
- dépassement de capacité de la variable
- clé alpha recevant la valeur de l'entier pas assez grande ?
- "de temps en temps" vraiment ou alors tous les 127ou les 32767 fois ?

Essaies avec : Monfichier2.Cle = MonFichier1.Cle

Espérant avoir aidé,

Victor


"Fredo" a écrit dans le message de news:
4cb3240d$0$5408$
Bonjour,

Dans une procédure de mise à jour de fichiers, j'écris dans 2 fichiers
à
la suite de la façon suivante :

MaCle est un entier = xxxx

MonFichier1.Cle = MaCle
...
hAjoute(MonFichier1)


Monfichier2.Cle = Macle
Monfichier2.Valeur1 = MaValeur1
Monfichier2.Valeur2 = MaValeur2
hAjoute(MonFichier2)


Entre le hajoute du fichier1 et celui du fichier2, il n'y a aucun
changement de valeur de MaCle, pourtant, de temps en temps, la
rubrique
Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la
bonne
valeur)

Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonne
valeur et que seule la rubrique MonFichier2.Cle est erronée.

Etant donnée que le lien entre les deux fichiers est bien entendu
MaCle,
vous imaginez les problèmes de cohérence.

Le pire du pire c'est que le problème est aléatoire, sur du monoposte
et
que les PC sur lesquels le problème survient sont tous ondulés. Le
problème est apparu en version 10 et en version 14.

La variable MaCle est une variable locale à la procédure.

Pour l'instant, je vais essayer de relire le dernier enregistrement
Fichier2 ecrit et tester la validité de Monfichier2.cle = Macle, mais
c'est quand même un peu flippant de ne pas pouvoir se fier à 100% à un
hajoute.

Si vous avez une piste ?

Merci d'avance.

Fred.








Bonjour,

Malheureusement, j'ai donné tout le code, le hraz est AVANT
l'affectation,
il n'y a pas d'écranversfichier, la clé n'est pas alpha (et elle est
correctement affectée pour le 1er fichier).

Le de temps en temps c'est une proportion de 3 ou 4 fois sur un mois
avec
800 à 900 enregistrements par jour, donc c'est très faible ( environ une
fois sur 6000 et uniquement chez deux clients sur 5000) ... mais sur une
application de facturation c'est brouillon lorsque l'on perd le lien
entre
une facture et son règlement.

Merci en tout cas pour votre réponse.

Fred.




Bonjour,

Je suis têtu :-)

MaCle est un entier = xxxx






je suppose que ce xxxx est une variable. Elle est passée en paramètre
dans
la procédure, comme par exemple :
Appel de la procédure : P_Maj(NumeroFact)
La procédure : Procedure P_Maj(_NumFact)

Si oui, entre
hAjoute(MonFichier1)






ET
Monfichier2.Cle = Macle







il n'y a vraiment rien ? pas d'appel à une autre procédure qui risque,
dans
certains cas particuliers, de toucher à _NumFact ou NumeroFact ? Si on
touche à NumeroFact, _NumFact est affecté par ce changement, d'ou ma
suggestion de faire plutôt "Monfichier2.Cle = MonFichier1.Cle"

Victor










Bonjour,


Effectivement, XXXX est une variable du type Procedure TrucMuche(pCle est
un entier)

La procédure est appelée de la façon suivante :

lCle est un entier
hlitdernier(MonFichier,MaCle)
lCle = monfichier.macle+1

TrucMuche(lCle)

et depuis j'ai même poussé le vice à mettre Procedure TrucMuche(local pCle
est un entier) en plus de la réaffectation de pCle dans une variable
locale à TrucMuche ...

Et j'ai bien contrôlé (plusieurs fois, ainsi que mes collègues) que la
variable local à TrucMuche n'avait pas d'affectation.

Malgré tout ça, j'ai encore des enregistrements avec cette rubrique qui
passe à 0.

Je pense qu'il doit y avoir quelque chose de particulier chez le client
car j'ai généré (à l'aide d'un automate) plus de 10.000 enregistrements
sur 4 système différents et je n'ai pas réussi à reproduire le phénomène
chez nous.

Fred




Bonjour,

Je ne vois plus que trois possibilités :
1) Doublons : un autre poste (ou en monoposte l'utilisateur lance le prog 2
fois) crée un enregistrement entre-temps. Il faudrait vérifier si tu as un
traitement suite à erreur qui ferait que tu crée l'enregistrement avec une
clé à 0
2) Ta clé n'est pas vraiment à zéro. Tu le vois comment ? Affichage dans ta
fenêtre ou par WdMap ? Est-elle vraiment à zéro JUSTE APRES près le hAjoute
?

3) un autre traitement met à zéro ta clé. Yaurait pas un Trigger qui traîne
?

Suggestion : comme ce n'est pas reproductible, mets donc à jour un mouchard
juste après le hAjoute (fichier txt avec datesys ; heuresys ; WinUser ;
pCle ; Monfichier2.Cle )

Victor





Salut,

L'application est lancée une seule fois, il n'y a pas de triggers. Pour
constater l'erreur, on a un utilitaire dans l'application qui vient
contrôler la validité des enregistrements mais on constate aussi le
problème dans wdmap.

On vient de rajouter un mouchard qui va systématiquement venir lire le
dernier enregistrement créé et si la clé est à 0, on va 1) écrire un log
sur le disque et 2) tenter de corriger l'erreur.

Pour ce qui est des doublons, c'est justement une clé AVEC doublons.

Après avoir eu la cliente au téléphone aujourd'hui, le seul truc "hors
norme" par rapport à nos autres clients, c'est a priori que l'OS est un
XP service pack 2 ... les autres sont en SP3.

Merci pour ces pistes.

Fred.
Avatar
VPSoft
"Fredo" a écrit dans le message de news:
4cb85ee6$0$7685$
Le 14/10/2010 18:14, VPSoft a écrit :
"Fredo" a écrit dans le message de news:
4cb6d7bf$0$7694$
Le 12/10/2010 18:02, VPSoft a écrit :
"Fredo" a écrit dans le message de news:
4cb408ee$0$7676$


Le 11/10/2010 20:53, VPSoft a écrit :
Bonsoir,
Je suppose que tu n'as pas donné tout le code, donc, en vrac,
quelques
pistes :
- hRaz conditionnel entre l'affectation et le hAjoute ?
- EcranVersFichier '' ''' '' ""
- dépassement de capacité de la variable
- clé alpha recevant la valeur de l'entier pas assez grande ?
- "de temps en temps" vraiment ou alors tous les 127ou les 32767 fois
?

Essaies avec : Monfichier2.Cle = MonFichier1.Cle

Espérant avoir aidé,

Victor


"Fredo" a écrit dans le message de
news:
4cb3240d$0$5408$
Bonjour,

Dans une procédure de mise à jour de fichiers, j'écris dans 2
fichiers
à
la suite de la façon suivante :

MaCle est un entier = xxxx

MonFichier1.Cle = MaCle
...
hAjoute(MonFichier1)


Monfichier2.Cle = Macle
Monfichier2.Valeur1 = MaValeur1
Monfichier2.Valeur2 = MaValeur2
hAjoute(MonFichier2)


Entre le hajoute du fichier1 et celui du fichier2, il n'y a aucun
changement de valeur de MaCle, pourtant, de temps en temps, la
rubrique
Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la
bonne
valeur)

Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la
bonne
valeur et que seule la rubrique MonFichier2.Cle est erronée.

Etant donnée que le lien entre les deux fichiers est bien entendu
MaCle,
vous imaginez les problèmes de cohérence.

Le pire du pire c'est que le problème est aléatoire, sur du
monoposte
et
que les PC sur lesquels le problème survient sont tous ondulés. Le
problème est apparu en version 10 et en version 14.

La variable MaCle est une variable locale à la procédure.

Pour l'instant, je vais essayer de relire le dernier enregistrement
Fichier2 ecrit et tester la validité de Monfichier2.cle = Macle,
mais
c'est quand même un peu flippant de ne pas pouvoir se fier à 100% à
un
hajoute.

Si vous avez une piste ?

Merci d'avance.

Fred.








Bonjour,

Malheureusement, j'ai donné tout le code, le hraz est AVANT
l'affectation,
il n'y a pas d'écranversfichier, la clé n'est pas alpha (et elle est
correctement affectée pour le 1er fichier).

Le de temps en temps c'est une proportion de 3 ou 4 fois sur un mois
avec
800 à 900 enregistrements par jour, donc c'est très faible ( environ
une
fois sur 6000 et uniquement chez deux clients sur 5000) ... mais sur
une
application de facturation c'est brouillon lorsque l'on perd le lien
entre
une facture et son règlement.

Merci en tout cas pour votre réponse.

Fred.




Bonjour,

Je suis têtu :-)

MaCle est un entier = xxxx






je suppose que ce xxxx est une variable. Elle est passée en paramètre
dans
la procédure, comme par exemple :
Appel de la procédure : P_Maj(NumeroFact)
La procédure : Procedure P_Maj(_NumFact)

Si oui, entre
hAjoute(MonFichier1)






ET
Monfichier2.Cle = Macle







il n'y a vraiment rien ? pas d'appel à une autre procédure qui risque,
dans
certains cas particuliers, de toucher à _NumFact ou NumeroFact ? Si on
touche à NumeroFact, _NumFact est affecté par ce changement, d'ou ma
suggestion de faire plutôt "Monfichier2.Cle = MonFichier1.Cle"

Victor










Bonjour,


Effectivement, XXXX est une variable du type Procedure TrucMuche(pCle
est
un entier)

La procédure est appelée de la façon suivante :

lCle est un entier
hlitdernier(MonFichier,MaCle)
lCle = monfichier.macle+1

TrucMuche(lCle)

et depuis j'ai même poussé le vice à mettre Procedure TrucMuche(local
pCle
est un entier) en plus de la réaffectation de pCle dans une variable
locale à TrucMuche ...

Et j'ai bien contrôlé (plusieurs fois, ainsi que mes collègues) que la
variable local à TrucMuche n'avait pas d'affectation.

Malgré tout ça, j'ai encore des enregistrements avec cette rubrique qui
passe à 0.

Je pense qu'il doit y avoir quelque chose de particulier chez le client
car j'ai généré (à l'aide d'un automate) plus de 10.000 enregistrements
sur 4 système différents et je n'ai pas réussi à reproduire le phénomène
chez nous.

Fred




Bonjour,

Je ne vois plus que trois possibilités :
1) Doublons : un autre poste (ou en monoposte l'utilisateur lance le prog
2
fois) crée un enregistrement entre-temps. Il faudrait vérifier si tu as
un
traitement suite à erreur qui ferait que tu crée l'enregistrement avec
une
clé à 0
2) Ta clé n'est pas vraiment à zéro. Tu le vois comment ? Affichage dans
ta
fenêtre ou par WdMap ? Est-elle vraiment à zéro JUSTE APRES près le
hAjoute
?

3) un autre traitement met à zéro ta clé. Yaurait pas un Trigger qui
traîne
?

Suggestion : comme ce n'est pas reproductible, mets donc à jour un
mouchard
juste après le hAjoute (fichier txt avec datesys ; heuresys ; WinUser ;
pCle ; Monfichier2.Cle )

Victor





Salut,

L'application est lancée une seule fois, il n'y a pas de triggers. Pour
constater l'erreur, on a un utilitaire dans l'application qui vient
contrôler la validité des enregistrements mais on constate aussi le
problème dans wdmap.

On vient de rajouter un mouchard qui va systématiquement venir lire le
dernier enregistrement créé et si la clé est à 0, on va 1) écrire un log
sur le disque et 2) tenter de corriger l'erreur.

Pour ce qui est des doublons, c'est justement une clé AVEC doublons.

Après avoir eu la cliente au téléphone aujourd'hui, le seul truc "hors
norme" par rapport à nos autres clients, c'est a priori que l'OS est un XP
service pack 2 ... les autres sont en SP3.

Merci pour ces pistes.

Fred.




Salut !
Bizarre... Ce truc attise ma curiosité. Penses à me tenir au courant le jour
ou tu trouveras.

- SP2 ou SP3 : je ne vois pas le rapport
- Doublons : c'était un exemple. Ca pourrait être aussi un traitement en cas
de hErreurIntegrite() ou autre, que tu ne vois pas tout de suite dans ton
code si, comme moi, tu passes par une classe pour tous les accès HF.
- Mouchard : tel que tu le décris, tu n'auras qu'une trace indiquant que tu
as trouvé un cas. Cela ne t'apportera rien de plus car tu ne sauras pas
quelles étaient les valeurs au moment du hAjoute, notamment pCle et
Monfichier2.Cle . Ce que je te proposais, c'est d'écrire systématiquement
ces éléments.

Bon courage pour la suite, La, je donne ma langue au chat...

Victor
Avatar
eric flament
Le 11/10/10 16:49, Fredo a écrit :
Bonjour,


bonjour,

Dans une procédure de mise à jour de fichiers, j'écris dans 2 fichiers à
la suite de la façon suivante :

MaCle est un entier = xxxx

MonFichier1.Cle = MaCle
...
hAjoute(MonFichier1)


Monfichier2.Cle = Macle
Monfichier2.Valeur1 = MaValeur1
Monfichier2.Valeur2 = MaValeur2
hAjoute(MonFichier2)


Entre le hajoute du fichier1 et celui du fichier2, il n'y a aucun
changement de valeur de MaCle, pourtant, de temps en temps, la rubrique
Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la bonne
valeur)

Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonne
valeur et que seule la rubrique MonFichier2.Cle est erronée.

Etant donnée que le lien entre les deux fichiers est bien entendu MaCle,
vous imaginez les problèmes de cohérence.

Le pire du pire c'est que le problème est aléatoire, sur du monoposte et
que les PC sur lesquels le problème survient sont tous ondulés. Le
problème est apparu en version 10 et en version 14.

La variable MaCle est une variable locale à la procédure.

Pour l'instant, je vais essayer de relire le dernier enregistrement
Fichier2 ecrit et tester la validité de Monfichier2.cle = Macle, mais
c'est quand même un peu flippant de ne pas pouvoir se fier à 100% à un
hajoute.

Si vous avez une piste ?

Merci d'avance.

Fred.



quelle est la valeur maximale que le champ monfichier1.cle ainsi que
monfichier2.clef acceptent

en clipper j"utilisait un truc du genre maclef ="100"+strzero(maclef,6)
qui faisait que maclef est une chaine de charactére contenant
"100000001" pour "100"+1

blocage de l'enregistrement du fichier qui contient les valeurs des
clefs avant incrémentation des valeurs,

eric
Avatar
Fredo
Le 17/10/2010 11:24, eric flament a écrit :
Le 11/10/10 16:49, Fredo a écrit :
Bonjour,


bonjour,

Dans une procédure de mise à jour de fichiers, j'écris dans 2 fichiers à
la suite de la façon suivante :

MaCle est un entier = xxxx

MonFichier1.Cle = MaCle
...
hAjoute(MonFichier1)


Monfichier2.Cle = Macle
Monfichier2.Valeur1 = MaValeur1
Monfichier2.Valeur2 = MaValeur2
hAjoute(MonFichier2)


Entre le hajoute du fichier1 et celui du fichier2, il n'y a aucun
changement de valeur de MaCle, pourtant, de temps en temps, la rubrique
Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la bonne
valeur)

Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonne
valeur et que seule la rubrique MonFichier2.Cle est erronée.

Etant donnée que le lien entre les deux fichiers est bien entendu MaCle,
vous imaginez les problèmes de cohérence.

Le pire du pire c'est que le problème est aléatoire, sur du monoposte et
que les PC sur lesquels le problème survient sont tous ondulés. Le
problème est apparu en version 10 et en version 14.

La variable MaCle est une variable locale à la procédure.

Pour l'instant, je vais essayer de relire le dernier enregistrement
Fichier2 ecrit et tester la validité de Monfichier2.cle = Macle, mais
c'est quand même un peu flippant de ne pas pouvoir se fier à 100% à un
hajoute.

Si vous avez une piste ?

Merci d'avance.

Fred.



quelle est la valeur maximale que le champ monfichier1.cle ainsi que
monfichier2.clef acceptent

en clipper j"utilisait un truc du genre maclef ="100"+strzero(maclef,6)
qui faisait que maclef est une chaine de charactére contenant
"100000001" pour "100"+1

blocage de l'enregistrement du fichier qui contient les valeurs des
clefs avant incrémentation des valeurs,

eric






Salut,

En fait c'est assez bizarre, après analyse sur x semaines en arrière, le
problème apparait sur 2 à 4 enregistrements, toujours à la suite les un
les autres, une fois maximum dans la journée, entre 8h et 10h30. Jamais
en dehors de cette plage horaire, jamais plusieurs fois dans la journée.

Pour la clé, pas de dépassement de valeur, car N va bloquer alors que
N+1 va passer sans problèmes. De plus monFichier1 et monFichier2 ont le
même type pour MaClé (entier non signé sur 4) et le 1er passe alors que
le deuxième bloque.


Fred
Avatar
VPSoft
"Fredo" a écrit dans le message de news:
4cbc40f6$0$5388$
Le 17/10/2010 11:24, eric flament a écrit :
Le 11/10/10 16:49, Fredo a écrit :
Bonjour,


bonjour,

Dans une procédure de mise à jour de fichiers, j'écris dans 2 fichiers à
la suite de la façon suivante :

MaCle est un entier = xxxx

MonFichier1.Cle = MaCle
...
hAjoute(MonFichier1)


Monfichier2.Cle = Macle
Monfichier2.Valeur1 = MaValeur1
Monfichier2.Valeur2 = MaValeur2
hAjoute(MonFichier2)


Entre le hajoute du fichier1 et celui du fichier2, il n'y a aucun
changement de valeur de MaCle, pourtant, de temps en temps, la rubrique
Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la bonne
valeur)

Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonne
valeur et que seule la rubrique MonFichier2.Cle est erronée.

Etant donnée que le lien entre les deux fichiers est bien entendu MaCle,
vous imaginez les problèmes de cohérence.

Le pire du pire c'est que le problème est aléatoire, sur du monoposte et
que les PC sur lesquels le problème survient sont tous ondulés. Le
problème est apparu en version 10 et en version 14.

La variable MaCle est une variable locale à la procédure.

Pour l'instant, je vais essayer de relire le dernier enregistrement
Fichier2 ecrit et tester la validité de Monfichier2.cle = Macle, mais
c'est quand même un peu flippant de ne pas pouvoir se fier à 100% à un
hajoute.

Si vous avez une piste ?

Merci d'avance.

Fred.



quelle est la valeur maximale que le champ monfichier1.cle ainsi que
monfichier2.clef acceptent

en clipper j"utilisait un truc du genre maclef ="100"+strzero(maclef,6)
qui faisait que maclef est une chaine de charactére contenant
"100000001" pour "100"+1

blocage de l'enregistrement du fichier qui contient les valeurs des
clefs avant incrémentation des valeurs,

eric






Salut,

En fait c'est assez bizarre, après analyse sur x semaines en arrière, le
problème apparait sur 2 à 4 enregistrements, toujours à la suite les un
les autres, une fois maximum dans la journée, entre 8h et 10h30. Jamais en
dehors de cette plage horaire, jamais plusieurs fois dans la journée.

Pour la clé, pas de dépassement de valeur, car N va bloquer alors que N+1
va passer sans problèmes. De plus monFichier1 et monFichier2 ont le même
type pour MaClé (entier non signé sur 4) et le 1er passe alors que le
deuxième bloque.


Fred



Salut !
Encore moi :-)

Il faudrait absolument savoir si c'est = 0 JUSTE APRES le hAjoute ou si ce
n'est pas remis à zéro plus tard, soit par une autre procédure (c.f. mes
messages précédents), soit par un autre programme (qui serait utilisé entre
8 et 10h30).
Comme suggéré plus haut, tu devrais déjà remplacer monfichier2.cle = pCle
par monfichier2.cle = monfichier1.cle
Au moins, là, tu serais certain qu'on ne lui demande pas d'écrire un
enregistrement avec clé à 0.
Autrement, tu fais directement hAjoute() ou tu passes par une classe ou
autre proc globale qui le fait ? Si classe, remplaces provisoirement par un
hAjoute directement dans le code de ta proc.

Victor
1 2