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.
>>> 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 rubriq ue >>> Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la bonne >>> valeur)
>>> Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonn e >>> valeur et que seule la rubrique MonFichier2.Cle est erronée.
>>> Etant donnée que le lien entre les deux fichiers est bien entendu M aCle, >>> vous imaginez les problèmes de cohérence.
>>> Le pire du pire c'est que le problème est aléatoire, sur du monop oste et >>> que les PC sur lesquels le problème survient sont tous ondulés. L e >>> 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èr e, 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. Jama is 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 q ue 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.cl e = 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
J'ai déjà vu ce genre de pb à cause d'une mémoire cache activée uniquement en écriture sur des disques réseaux .
De mémoire nous avions trouvé la solution en forçant l'écriture directe.
Si ca peut vous aider ...
cordialement.
On 18 oct, 17:25, "VPSoft" <vps...@wanadoo.fr> wrote:
"Fredo" <Fr...@gb-informatique.com> a écrit dans le message de news:
4cbc40f6$0$5388$ba4ac...@reader.news.orange.fr...
> 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 f ichiers à
>>> la suite de la façon suivante :
>>> 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 rubriq ue
>>> Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la bonne
>>> valeur)
>>> Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonn e
>>> valeur et que seule la rubrique MonFichier2.Cle est erronée.
>>> Etant donnée que le lien entre les deux fichiers est bien entendu M aCle,
>>> vous imaginez les problèmes de cohérence.
>>> Le pire du pire c'est que le problème est aléatoire, sur du monop oste et
>>> que les PC sur lesquels le problème survient sont tous ondulés. L e
>>> 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èr e, 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. Jama is 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 q ue 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.cl e = 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
J'ai déjà vu ce genre de pb à cause d'une mémoire cache activée
uniquement en écriture sur des disques réseaux .
De mémoire nous avions trouvé la solution en forçant l'écriture
directe.
>>> 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 rubriq ue >>> Monfichier2.Cle est égale à 0 (alors que MonFichier1.Cle à bien la bonne >>> valeur)
>>> Le pire, c'est que MonFichier2.Valeur1, Valeur2, ... ont bien la bonn e >>> valeur et que seule la rubrique MonFichier2.Cle est erronée.
>>> Etant donnée que le lien entre les deux fichiers est bien entendu M aCle, >>> vous imaginez les problèmes de cohérence.
>>> Le pire du pire c'est que le problème est aléatoire, sur du monop oste et >>> que les PC sur lesquels le problème survient sont tous ondulés. L e >>> 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èr e, 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. Jama is 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 q ue 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.cl e = 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
J'ai déjà vu ce genre de pb à cause d'une mémoire cache activée uniquement en écriture sur des disques réseaux .
De mémoire nous avions trouvé la solution en forçant l'écriture directe.
Si ca peut vous aider ...
cordialement.
Fredo
Le 19/10/2010 11:23, vann a écrit :
On 18 oct, 17:25, "VPSoft" wrote:
"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 :
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
J'ai déjà vu ce genre de pb à cause d'une mémoire cache activée uniquement en écriture sur des disques réseaux .
De mémoire nous avions trouvé la solution en forçant l'écriture directe.
Si ca peut vous aider ...
cordialement.
Bonjour,
Pour vérifier si c'est le hajoute qui foire ou si le fichier est modifié apres coup, on fait une lecture juste après le hajoute (avec enregistrement des données pertinentes).
Pour le coup d'une mise en cache éventuelle, j'ai forcé l'écriture avec le hforceecriture.
C'est en place chez le client et on attends la suite.
Merci à vous deux.
Fred.
Le 19/10/2010 11:23, vann a écrit :
On 18 oct, 17:25, "VPSoft"<vps...@wanadoo.fr> wrote:
"Fredo"<Fr...@gb-informatique.com> a écrit dans le message de news:
4cbc40f6$0$5388$ba4ac...@reader.news.orange.fr...
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 :
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
J'ai déjà vu ce genre de pb à cause d'une mémoire cache activée
uniquement en écriture sur des disques réseaux .
De mémoire nous avions trouvé la solution en forçant l'écriture
directe.
Si ca peut vous aider ...
cordialement.
Bonjour,
Pour vérifier si c'est le hajoute qui foire ou si le fichier est modifié
apres coup, on fait une lecture juste après le hajoute (avec
enregistrement des données pertinentes).
Pour le coup d'une mise en cache éventuelle, j'ai forcé l'écriture avec
le hforceecriture.
C'est en place chez le client et on attends la suite.
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
J'ai déjà vu ce genre de pb à cause d'une mémoire cache activée uniquement en écriture sur des disques réseaux .
De mémoire nous avions trouvé la solution en forçant l'écriture directe.
Si ca peut vous aider ...
cordialement.
Bonjour,
Pour vérifier si c'est le hajoute qui foire ou si le fichier est modifié apres coup, on fait une lecture juste après le hajoute (avec enregistrement des données pertinentes).
Pour le coup d'une mise en cache éventuelle, j'ai forcé l'écriture avec le hforceecriture.
C'est en place chez le client et on attends la suite.
