Dans un traitement, j'utilise la fonction HRAZ(NomFichierARéinitialiser)
pour remettre tous les champs à la valeur d'origine (0 dans mon cas).
Malheureusement, cette fonction ne fonctionne pas toujours. En effet, dans
le code ci-dessous, il arrive de manière tout à fait reproductible que l'un
des champs de la table ait une valeur différente de 0 (et dont je n'ai
absolument aucune idée d'ou elle peut bien venir !)
Par contre, si je modifie le code en mettant le HRAZ juste avant
l'assignation des valeurs (c'est à dire en première position dans la boucle
TANTQUE), le code semble parfaitement fonctionner pour l'instant.
Ce fonctionnement est-il normal et y a-t-il des précautions particulières à
prendre avec cette fonction HRAZ. A noter que le champ récupérant la valeur
mystère n'est pas un des champs auquel j'assigne une valeur avant le
HAjoute.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Haefele
"AIOE" a écrit
Par contre, si je modifie le code en mettant le HRAZ juste avant l'assignation des valeurs (c'est à dire en première position dans la boucle TANTQUE), le code semble parfaitement fonctionner pour l'instant.
A priori il parait de toute façon plus logique de le mettre juste après le TANTQUE car dans le cas contraire l'intialisation de ton premier enregistrement n'est pas faite, ne serait-ce d'ailleurs pas sur ce premier enregistrement que tu constates le problème ?
Amicalement,
Emmanuel Haefelé.
"AIOE" <berthemet.david@neuf.fr> a écrit
Par contre, si je modifie le code en mettant le HRAZ juste avant
l'assignation des valeurs (c'est à dire en première position dans la
boucle TANTQUE), le code semble parfaitement fonctionner pour l'instant.
A priori il parait de toute façon plus logique de le mettre juste après le
TANTQUE car dans le cas contraire l'intialisation de ton premier
enregistrement n'est pas faite, ne serait-ce d'ailleurs pas sur ce premier
enregistrement que tu constates le problème ?
Par contre, si je modifie le code en mettant le HRAZ juste avant l'assignation des valeurs (c'est à dire en première position dans la boucle TANTQUE), le code semble parfaitement fonctionner pour l'instant.
A priori il parait de toute façon plus logique de le mettre juste après le TANTQUE car dans le cas contraire l'intialisation de ton premier enregistrement n'est pas faite, ne serait-ce d'ailleurs pas sur ce premier enregistrement que tu constates le problème ?
Amicalement,
Emmanuel Haefelé.
David Berthemet
Merci pour l'intérêt porté à mon problème. A posteriori, il me semble aussi plus logique de le mettre à cet endroit, mais dans un premier temps, j'avais pensé assez logique de remettre les champs à 0 après leur avoir attribué une valeur ! Par contre, ce n'est pas sur le 1er enregistrement que ce pose le problème et la valeur récupérée ne semble pas correspondre à une valeur précédemment assignée. Cela me semble donc plutôt bizarre.
Cordialement,
David Berthemet
"Emmanuel Haefele" a écrit dans le message de news: 45660c3a$0$5082$
"AIOE" a écrit
Par contre, si je modifie le code en mettant le HRAZ juste avant l'assignation des valeurs (c'est à dire en première position dans la boucle TANTQUE), le code semble parfaitement fonctionner pour l'instant.
A priori il parait de toute façon plus logique de le mettre juste après le TANTQUE car dans le cas contraire l'intialisation de ton premier enregistrement n'est pas faite, ne serait-ce d'ailleurs pas sur ce premier enregistrement que tu constates le problème ?
Amicalement,
Emmanuel Haefelé.
Merci pour l'intérêt porté à mon problème.
A posteriori, il me semble aussi plus logique de le mettre à cet endroit,
mais dans un premier temps, j'avais pensé assez logique de remettre les
champs à 0 après leur avoir attribué une valeur !
Par contre, ce n'est pas sur le 1er enregistrement que ce pose le problème
et la valeur récupérée ne semble pas correspondre à une valeur précédemment
assignée. Cela me semble donc plutôt bizarre.
Cordialement,
David Berthemet
"Emmanuel Haefele" <e.haefele@windasso.org> a écrit dans le message de news:
45660c3a$0$5082$ba4acef3@news.orange.fr...
"AIOE" <berthemet.david@neuf.fr> a écrit
Par contre, si je modifie le code en mettant le HRAZ juste avant
l'assignation des valeurs (c'est à dire en première position dans la
boucle TANTQUE), le code semble parfaitement fonctionner pour l'instant.
A priori il parait de toute façon plus logique de le mettre juste après le
TANTQUE car dans le cas contraire l'intialisation de ton premier
enregistrement n'est pas faite, ne serait-ce d'ailleurs pas sur ce premier
enregistrement que tu constates le problème ?
Merci pour l'intérêt porté à mon problème. A posteriori, il me semble aussi plus logique de le mettre à cet endroit, mais dans un premier temps, j'avais pensé assez logique de remettre les champs à 0 après leur avoir attribué une valeur ! Par contre, ce n'est pas sur le 1er enregistrement que ce pose le problème et la valeur récupérée ne semble pas correspondre à une valeur précédemment assignée. Cela me semble donc plutôt bizarre.
Cordialement,
David Berthemet
"Emmanuel Haefele" a écrit dans le message de news: 45660c3a$0$5082$
"AIOE" a écrit
Par contre, si je modifie le code en mettant le HRAZ juste avant l'assignation des valeurs (c'est à dire en première position dans la boucle TANTQUE), le code semble parfaitement fonctionner pour l'instant.
A priori il parait de toute façon plus logique de le mettre juste après le TANTQUE car dans le cas contraire l'intialisation de ton premier enregistrement n'est pas faite, ne serait-ce d'ailleurs pas sur ce premier enregistrement que tu constates le problème ?
Amicalement,
Emmanuel Haefelé.
Michel
AIOE a écrit :
Bonsoir,
Dans un traitement, j'utilise la fonction HRAZ(NomFichierARéinitialiser) pour remettre tous les champs à la valeur d'origine (0 dans mon cas). Malheureusement, cette fonction ne fonctionne pas toujours. En effet, dans le code ci-dessous, il arrive de manière tout à fait reproductible que l'un des champs de la table ait une valeur différente de 0 (et dont je n'ai absolument aucune idée d'ou elle peut bien venir !)
Par contre, si je modifie le code en mettant le HRAZ juste avant l'assignation des valeurs (c'est à dire en première position dans la boucle TANTQUE), le code semble parfaitement fonctionner pour l'instant.
Ce fonctionnement est-il normal et y a-t-il des précautions particulières à prendre avec cette fonction HRAZ. A noter que le champ récupérant la valeur mystère n'est pas un des champs auquel j'assigne une valeur avant le HAjoute.
Merci d'avance pour tout commentaire.
David Berthemet
Je ne vois pas trop l'intérêt de mettre HRAZ dans la boucle.
Une seule fois AVANT la boucle devrait suffire, et encore seulement dans le cas ou un des champs de TblTempEtatDuMateriel ne serait pas affecté explicitement avant le HAjoute, ensuite, il n'y a aucune raison pour que les valeurs ne correspondent pas à celles affectées.
Maintenant, au sujet de ce tu constates c'est effectivement bizarre. Cette valeur ressemble à quoi ? toujours la même ?
Michel
AIOE a écrit :
Bonsoir,
Dans un traitement, j'utilise la fonction HRAZ(NomFichierARéinitialiser)
pour remettre tous les champs à la valeur d'origine (0 dans mon cas).
Malheureusement, cette fonction ne fonctionne pas toujours. En effet, dans
le code ci-dessous, il arrive de manière tout à fait reproductible que l'un
des champs de la table ait une valeur différente de 0 (et dont je n'ai
absolument aucune idée d'ou elle peut bien venir !)
Par contre, si je modifie le code en mettant le HRAZ juste avant
l'assignation des valeurs (c'est à dire en première position dans la boucle
TANTQUE), le code semble parfaitement fonctionner pour l'instant.
Ce fonctionnement est-il normal et y a-t-il des précautions particulières à
prendre avec cette fonction HRAZ. A noter que le champ récupérant la valeur
mystère n'est pas un des champs auquel j'assigne une valeur avant le
HAjoute.
Merci d'avance pour tout commentaire.
David Berthemet
Je ne vois pas trop l'intérêt de mettre HRAZ dans la boucle.
Une seule fois AVANT la boucle devrait suffire, et encore seulement dans
le cas ou un des champs de TblTempEtatDuMateriel ne serait pas affecté
explicitement avant le HAjoute, ensuite, il n'y a aucune raison pour que
les valeurs ne correspondent pas à celles affectées.
Maintenant, au sujet de ce tu constates c'est effectivement bizarre.
Cette valeur ressemble à quoi ? toujours la même ?
Dans un traitement, j'utilise la fonction HRAZ(NomFichierARéinitialiser) pour remettre tous les champs à la valeur d'origine (0 dans mon cas). Malheureusement, cette fonction ne fonctionne pas toujours. En effet, dans le code ci-dessous, il arrive de manière tout à fait reproductible que l'un des champs de la table ait une valeur différente de 0 (et dont je n'ai absolument aucune idée d'ou elle peut bien venir !)
Par contre, si je modifie le code en mettant le HRAZ juste avant l'assignation des valeurs (c'est à dire en première position dans la boucle TANTQUE), le code semble parfaitement fonctionner pour l'instant.
Ce fonctionnement est-il normal et y a-t-il des précautions particulières à prendre avec cette fonction HRAZ. A noter que le champ récupérant la valeur mystère n'est pas un des champs auquel j'assigne une valeur avant le HAjoute.
Merci d'avance pour tout commentaire.
David Berthemet
Je ne vois pas trop l'intérêt de mettre HRAZ dans la boucle.
Une seule fois AVANT la boucle devrait suffire, et encore seulement dans le cas ou un des champs de TblTempEtatDuMateriel ne serait pas affecté explicitement avant le HAjoute, ensuite, il n'y a aucune raison pour que les valeurs ne correspondent pas à celles affectées.
Maintenant, au sujet de ce tu constates c'est effectivement bizarre. Cette valeur ressemble à quoi ? toujours la même ?
Michel
Antoine
On a eu ce genre de souci, et chez nous en fait c'était pas le HRaz, mais l'habitude faisant on a immédiatement pensé à un bug dans HRaz... pour finir c'était un appel de procédure avec la rubrique en question passée en paramètre, en simple lecture croyait-on, la procédure en appelait une autre, qui en appelait une 3ème, et au fin fond des appels, il y avait une modif sur le paramètre passé, mais à cause de l'empilement des appels on n'avait pas fait gaffe que le paramètre correspondait à une rubrique fichier...!
Notre solution: utiliser proprement le passage par adresse et le passage par valeur. Maintenant on fait systématiquement des entêtes de procédures ainsi:
PROCEDURE MaProcédure(LOCAL stChaine est une chaine,LOCAL inEntier est un entier) en précisant LOCAL si le paramétre est passé par valeur (n'est pas destiné à être modifié). Ca nous évite maintenant plein de bugs potentiels!
Voilà enfin tout ça pour dire que ton bug est peut-être caché dans tes "..." où il y a peut-être un appel de procédure que tu pensais innocent ???
Sinon je sèche, c'est bizarre en effet...!
Bon courage, Antoine
"AIOE" a écrit dans le message de news: ek4o7t$qb6$
Bonsoir,
Dans un traitement, j'utilise la fonction HRAZ(NomFichierARéinitialiser) pour remettre tous les champs à la valeur d'origine (0 dans mon cas). Malheureusement, cette fonction ne fonctionne pas toujours. En effet, dans le code ci-dessous, il arrive de manière tout à fait reproductible que l'un des champs de la table ait une valeur différente de 0 (et dont je n'ai absolument aucune idée d'ou elle peut bien venir !)
Par contre, si je modifie le code en mettant le HRAZ juste avant l'assignation des valeurs (c'est à dire en première position dans la boucle TANTQUE), le code semble parfaitement fonctionner pour l'instant.
Ce fonctionnement est-il normal et y a-t-il des précautions particulières à prendre avec cette fonction HRAZ. A noter que le champ récupérant la valeur mystère n'est pas un des champs auquel j'assigne une valeur avant le HAjoute.
Merci d'avance pour tout commentaire.
David Berthemet
On a eu ce genre de souci, et chez nous en fait c'était pas le HRaz, mais
l'habitude faisant on a immédiatement pensé à un bug dans HRaz... pour finir
c'était un appel de procédure avec la rubrique en question passée en
paramètre, en simple lecture croyait-on, la procédure en appelait une autre,
qui en appelait une 3ème, et au fin fond des appels, il y avait une modif
sur le paramètre passé, mais à cause de l'empilement des appels on n'avait
pas fait gaffe que le paramètre correspondait à une rubrique fichier...!
Notre solution: utiliser proprement le passage par adresse et le passage par
valeur. Maintenant on fait systématiquement des entêtes de procédures ainsi:
PROCEDURE MaProcédure(LOCAL stChaine est une chaine,LOCAL inEntier est un
entier)
en précisant LOCAL si le paramétre est passé par valeur (n'est pas destiné à
être modifié). Ca nous évite maintenant plein de bugs potentiels!
Voilà enfin tout ça pour dire que ton bug est peut-être caché dans tes "..."
où il y a peut-être un appel de procédure que tu pensais innocent ???
Sinon je sèche, c'est bizarre en effet...!
Bon courage,
Antoine
"AIOE" <berthemet.david@neuf.fr> a écrit dans le message de news:
ek4o7t$qb6$1@aioe.server.aioe.org...
Bonsoir,
Dans un traitement, j'utilise la fonction HRAZ(NomFichierARéinitialiser)
pour remettre tous les champs à la valeur d'origine (0 dans mon cas).
Malheureusement, cette fonction ne fonctionne pas toujours. En effet, dans
le code ci-dessous, il arrive de manière tout à fait reproductible que
l'un des champs de la table ait une valeur différente de 0 (et dont je
n'ai absolument aucune idée d'ou elle peut bien venir !)
Par contre, si je modifie le code en mettant le HRAZ juste avant
l'assignation des valeurs (c'est à dire en première position dans la
boucle TANTQUE), le code semble parfaitement fonctionner pour l'instant.
Ce fonctionnement est-il normal et y a-t-il des précautions particulières
à prendre avec cette fonction HRAZ. A noter que le champ récupérant la
valeur mystère n'est pas un des champs auquel j'assigne une valeur avant
le HAjoute.
On a eu ce genre de souci, et chez nous en fait c'était pas le HRaz, mais l'habitude faisant on a immédiatement pensé à un bug dans HRaz... pour finir c'était un appel de procédure avec la rubrique en question passée en paramètre, en simple lecture croyait-on, la procédure en appelait une autre, qui en appelait une 3ème, et au fin fond des appels, il y avait une modif sur le paramètre passé, mais à cause de l'empilement des appels on n'avait pas fait gaffe que le paramètre correspondait à une rubrique fichier...!
Notre solution: utiliser proprement le passage par adresse et le passage par valeur. Maintenant on fait systématiquement des entêtes de procédures ainsi:
PROCEDURE MaProcédure(LOCAL stChaine est une chaine,LOCAL inEntier est un entier) en précisant LOCAL si le paramétre est passé par valeur (n'est pas destiné à être modifié). Ca nous évite maintenant plein de bugs potentiels!
Voilà enfin tout ça pour dire que ton bug est peut-être caché dans tes "..." où il y a peut-être un appel de procédure que tu pensais innocent ???
Sinon je sèche, c'est bizarre en effet...!
Bon courage, Antoine
"AIOE" a écrit dans le message de news: ek4o7t$qb6$
Bonsoir,
Dans un traitement, j'utilise la fonction HRAZ(NomFichierARéinitialiser) pour remettre tous les champs à la valeur d'origine (0 dans mon cas). Malheureusement, cette fonction ne fonctionne pas toujours. En effet, dans le code ci-dessous, il arrive de manière tout à fait reproductible que l'un des champs de la table ait une valeur différente de 0 (et dont je n'ai absolument aucune idée d'ou elle peut bien venir !)
Par contre, si je modifie le code en mettant le HRAZ juste avant l'assignation des valeurs (c'est à dire en première position dans la boucle TANTQUE), le code semble parfaitement fonctionner pour l'instant.
Ce fonctionnement est-il normal et y a-t-il des précautions particulières à prendre avec cette fonction HRAZ. A noter que le champ récupérant la valeur mystère n'est pas un des champs auquel j'assigne une valeur avant le HAjoute.
Merci d'avance pour tout commentaire.
David Berthemet
david_be
Bonjour,
Dans mon cas, la table en question est recréée avec un Hcréation juste avant la procédure en cause et le champ n'est pas appelé par aucune autre procédure avant la procédure en cause. Par contre, ce problème survient quand on réalise plusieurs appels de suite à cette procédure. Le premier appel ne pose jamais de problème mais il arrive très souvent qu'un des appels suivant fasse apparaître ce problème.
J'ai du mal à comprendre.
Cordialement,
David Berthemet
Antoine a écrit :
On a eu ce genre de souci, et chez nous en fait c'était pas le HRaz, ma is l'habitude faisant on a immédiatement pensé à un bug dans HRaz... p our finir c'était un appel de procédure avec la rubrique en question passée en paramètre, en simple lecture croyait-on, la procédure en appelait une autre, qui en appelait une 3ème, et au fin fond des appels, il y avait une mod if sur le paramètre passé, mais à cause de l'empilement des appels on n'avait pas fait gaffe que le paramètre correspondait à une rubrique fichier. ..!
Notre solution: utiliser proprement le passage par adresse et le passage par valeur. Maintenant on fait systématiquement des entêtes de procédur es ainsi:
PROCEDURE MaProcédure(LOCAL stChaine est une chaine,LOCAL inEntier est un entier) en précisant LOCAL si le paramétre est passé par valeur (n'est pas destiné à être modifié). Ca nous évite maintenant plein de bugs potentiels!
Voilà enfin tout ça pour dire que ton bug est peut-être caché dan s tes "..." où il y a peut-être un appel de procédure que tu pensais innocent ? ??
Sinon je sèche, c'est bizarre en effet...!
Bon courage, Antoine
Bonjour,
Dans mon cas, la table en question est recréée avec un Hcréation
juste avant la procédure en cause et le champ n'est pas appelé par
aucune autre procédure avant la procédure en cause.
Par contre, ce problème survient quand on réalise plusieurs appels de
suite à cette procédure. Le premier appel ne pose jamais de problème
mais il arrive très souvent qu'un des appels suivant fasse apparaître
ce problème.
J'ai du mal à comprendre.
Cordialement,
David Berthemet
Antoine a écrit :
On a eu ce genre de souci, et chez nous en fait c'était pas le HRaz, ma is
l'habitude faisant on a immédiatement pensé à un bug dans HRaz... p our finir
c'était un appel de procédure avec la rubrique en question passée en
paramètre, en simple lecture croyait-on, la procédure en appelait une autre,
qui en appelait une 3ème, et au fin fond des appels, il y avait une mod if
sur le paramètre passé, mais à cause de l'empilement des appels on n'avait
pas fait gaffe que le paramètre correspondait à une rubrique fichier. ..!
Notre solution: utiliser proprement le passage par adresse et le passage par
valeur. Maintenant on fait systématiquement des entêtes de procédur es ainsi:
PROCEDURE MaProcédure(LOCAL stChaine est une chaine,LOCAL inEntier est un
entier)
en précisant LOCAL si le paramétre est passé par valeur (n'est pas destiné à
être modifié). Ca nous évite maintenant plein de bugs potentiels!
Voilà enfin tout ça pour dire que ton bug est peut-être caché dan s tes "..."
où il y a peut-être un appel de procédure que tu pensais innocent ? ??
Dans mon cas, la table en question est recréée avec un Hcréation juste avant la procédure en cause et le champ n'est pas appelé par aucune autre procédure avant la procédure en cause. Par contre, ce problème survient quand on réalise plusieurs appels de suite à cette procédure. Le premier appel ne pose jamais de problème mais il arrive très souvent qu'un des appels suivant fasse apparaître ce problème.
J'ai du mal à comprendre.
Cordialement,
David Berthemet
Antoine a écrit :
On a eu ce genre de souci, et chez nous en fait c'était pas le HRaz, ma is l'habitude faisant on a immédiatement pensé à un bug dans HRaz... p our finir c'était un appel de procédure avec la rubrique en question passée en paramètre, en simple lecture croyait-on, la procédure en appelait une autre, qui en appelait une 3ème, et au fin fond des appels, il y avait une mod if sur le paramètre passé, mais à cause de l'empilement des appels on n'avait pas fait gaffe que le paramètre correspondait à une rubrique fichier. ..!
Notre solution: utiliser proprement le passage par adresse et le passage par valeur. Maintenant on fait systématiquement des entêtes de procédur es ainsi:
PROCEDURE MaProcédure(LOCAL stChaine est une chaine,LOCAL inEntier est un entier) en précisant LOCAL si le paramétre est passé par valeur (n'est pas destiné à être modifié). Ca nous évite maintenant plein de bugs potentiels!
Voilà enfin tout ça pour dire que ton bug est peut-être caché dan s tes "..." où il y a peut-être un appel de procédure que tu pensais innocent ? ??
Sinon je sèche, c'est bizarre en effet...!
Bon courage, Antoine
Michel
a écrit :
Bonjour,
Dans mon cas, la table en question est recréée avec un Hcréation juste avant la procédure en cause et le champ n'est pas appelé par aucune autre procédure avant la procédure en cause. Par contre, ce problème survient quand on réalise plusieurs appels de suite à cette procédure. Le premier appel ne pose jamais de problème mais il arrive très souvent qu'un des appels suivant fasse apparaître ce problème.
J'ai du mal à comprendre.
Cordialement,
Si tu peux isoler ce comportement dans un petit projet avec juste les 2 tables et la procédure,
ce serait plus facile pour comprendre si toutefois hors du contexte ce comportement perdure.
mais je sais que faire cela prends du temps.
Michel
david_be@club-internet.fr a écrit :
Bonjour,
Dans mon cas, la table en question est recréée avec un Hcréation
juste avant la procédure en cause et le champ n'est pas appelé par
aucune autre procédure avant la procédure en cause.
Par contre, ce problème survient quand on réalise plusieurs appels de
suite à cette procédure. Le premier appel ne pose jamais de problème
mais il arrive très souvent qu'un des appels suivant fasse apparaître
ce problème.
J'ai du mal à comprendre.
Cordialement,
Si tu peux isoler ce comportement dans un petit projet avec juste les 2
tables et la procédure,
ce serait plus facile pour comprendre si toutefois hors du contexte ce
comportement perdure.
Dans mon cas, la table en question est recréée avec un Hcréation juste avant la procédure en cause et le champ n'est pas appelé par aucune autre procédure avant la procédure en cause. Par contre, ce problème survient quand on réalise plusieurs appels de suite à cette procédure. Le premier appel ne pose jamais de problème mais il arrive très souvent qu'un des appels suivant fasse apparaître ce problème.
J'ai du mal à comprendre.
Cordialement,
Si tu peux isoler ce comportement dans un petit projet avec juste les 2 tables et la procédure,
ce serait plus facile pour comprendre si toutefois hors du contexte ce comportement perdure.
mais je sais que faire cela prends du temps.
Michel
Dc
Bonjour,
Dans son message précédent, a écrit :
Bonjour,
Juste si tu as tjrs pas d'explication.. en mettant le nom du fichier avec le tant que pas hendehors ...
a plus ..
-- ------------------------------------------------------------- www.ctc-soft.com NOUV : Logiciel de Gestion Documentaire Comptabilité shareware Logiciels de Gestion de saisie terrain Spécialisé Tournées de boulangers -------------------------------------------------------------
Bonjour,
Dans son message précédent, david_be@club-internet.fr a écrit :
Bonjour,
Juste si tu as tjrs pas d'explication..
en mettant le nom du fichier avec le tant que pas hendehors ...
a plus ..
--
-------------------------------------------------------------
www.ctc-soft.com
NOUV : Logiciel de Gestion Documentaire
Comptabilité shareware
Logiciels de Gestion de saisie terrain
Spécialisé Tournées de boulangers
-------------------------------------------------------------
