[WD9] Corruption fichier en lecture seule

JeAn-PhI a écrit :

bonjour

j'ai un fichier HF dont voici la description :

Identifiant : clé composée des 2 rubriques
Année : date (AAAAMMJJ)
code : un code (2 caractères)

ce fichier n'est que lu et jamais il n'est modifié ou mis à jour, hors
j'ai souvent une corruption de e fichier

nota : les appli sont en réseau HF classic, les accès lecture de font
par les fonctions HLit....

je ne sais plus où chercher, un peu d'aide serait bienvenue

Un problème disque ?
il faudrait tester après un scandisk et une défrag.

--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com

jacques trepp avait soumis l'idée :

JeAn-PhI a écrit :

bonjour

j'ai un fichier HF dont voici la description :

Identifiant : clé composée des 2 rubriques
Année : date (AAAAMMJJ)
code : un code (2 caractères)

ce fichier n'est que lu et jamais il n'est modifié ou mis à jour, hors j'ai
souvent une corruption de e fichier

nota : les appli sont en réseau HF classic, les accès lecture de font par
les fonctions HLit....

je ne sais plus où chercher, un peu d'aide serait bienvenue

Un problème disque ?
il faudrait tester après un scandisk et une défrag.

cela se produit chez plusieurs clients différent après une réindexation
tout rentre dans l'ordre

j'ai une fenêtre ddans laquelle il y a la date et le code en fontion de
la date je la compare à la rubrique Année de mon fichier pour vérifier
le code
exemple :

szAnneeRef1 = "20000101"
szAnneeRef2 = "19991231"
si CHP_DATE_SAISIE < szAnneeRef1 alors

hlitrecherchepremier(MonFichier,MaCléCompo,hconstruitvalclé(MonFichier,MaCléCompo,szAnneeRef1,CHP_CODE_SAISIE))
sinon

hlitrecherchepremier(MonFichier,MaCléCompo,hconstruitvalclé(MonFichier,MaCléCompo,szAnneeRef2,CHP_CODE_SAISIE))
fin
si pas htrouve(MonFichier) alors
erreur("le code n'est pas bon")
reprisesaisie(CHP_CODE_SAISIE)
fin

--
Cordialement JeAn-PhI

JeAn-PhI a exprimé avec précision :

bonjour

j'ai un fichier HF dont voici la description :

Identifiant : clé composée des 2 rubriques
Année : date (AAAAMMJJ)
code : un code (2 caractères)

ce fichier n'est que lu et jamais il n'est modifié ou mis à jour, hors j'ai
souvent une corruption de e fichier

nota : les appli sont en réseau HF classic, les accès lecture de font par les
fonctions HLit....

je ne sais plus où chercher, un peu d'aide serait bienvenue

Essaie de fermer systématiquement le fichier après lecture.
J'ai déjà rencontré cela sur des fichiers d'historiques en WD5.5 et la
fermeture des fichiers a résolu mon problème.

Cordialement.

--
Eric Laurent
nospam.laurent.systel@wanadoo.fr
(enlever nospam.)

Eric Laurent vient de nous annoncer :

JeAn-PhI a exprimé avec précision :

bonjour

j'ai un fichier HF dont voici la description :

Identifiant : clé composée des 2 rubriques
Année : date (AAAAMMJJ)
code : un code (2 caractères)

ce fichier n'est que lu et jamais il n'est modifié ou mis à jour, hors j'ai
souvent une corruption de e fichier

nota : les appli sont en réseau HF classic, les accès lecture de font par
les fonctions HLit....

je ne sais plus où chercher, un peu d'aide serait bienvenue

Essaie de fermer systématiquement le fichier après lecture.
J'ai déjà rencontré cela sur des fichiers d'historiques en WD5.5 et la
fermeture des fichiers a résolu mon problème.

Cordialement.

ok je vais essayer et wait and see

--
Cordialement JeAn-PhI

"JeAn-PhI" <no.spam@spam.fr> a écrit dans le message de news:
mn.22d97d6a044b3abc.49289@spam.fr...

jacques trepp avait soumis l'idée :

JeAn-PhI a écrit :

bonjour

j'ai un fichier HF dont voici la description :

Identifiant : clé composée des 2 rubriques
Année : date (AAAAMMJJ)
code : un code (2 caractères)

ce fichier n'est que lu et jamais il n'est modifié ou mis à jour, hors
j'ai souvent une corruption de e fichier

nota : les appli sont en réseau HF classic, les accès lecture de font
par les fonctions HLit....

je ne sais plus où chercher, un peu d'aide serait bienvenue

Un problème disque ?
il faudrait tester après un scandisk et une défrag.

cela se produit chez plusieurs clients différent après une réindexation
tout rentre dans l'ordre

j'ai une fenêtre ddans laquelle il y a la date et le code en fontion de la
date je la compare à la rubrique Année de mon fichier pour vérifier le
code
exemple :

szAnneeRef1 = "20000101"
szAnneeRef2 = "19991231"
si CHP_DATE_SAISIE < szAnneeRef1 alors

hlitrecherchepremier(MonFichier,MaCléCompo,hconstruitvalclé(MonFichier,MaCléCompo,szAnneeRef1,CHP_CODE_SAISIE))
sinon

hlitrecherchepremier(MonFichier,MaCléCompo,hconstruitvalclé(MonFichier,MaCléCompo,szAnneeRef2,CHP_CODE_SAISIE))
fin
si pas htrouve(MonFichier) alors
erreur("le code n'est pas bon")
reprisesaisie(CHP_CODE_SAISIE)
fin

--
Cordialement JeAn-PhI

Bonjour,

Un truc tout bête peut être, comme par exemple :
- nom du fichier dans une variable qui ne serait pas ensuite correctement
mise à jour => on écrit dedans croyant qu'on est sur un autre fichier
- Mauvaise utilisation d' Alias. J'ai remarqué qu'il faut faire très, très
attention dans l'utilisation de Alias, changeRep, changeNom. Il faut
toujours tester le code retour

Espérant aider,

Victor

VPSoft avait prétendu :

Bonjour,

Un truc tout bête peut être, comme par exemple :
- nom du fichier dans une variable qui ne serait pas ensuite correctement
mise à jour => on écrit dedans croyant qu'on est sur un autre fichier
- Mauvaise utilisation d' Alias. J'ai remarqué qu'il faut faire très, très
attention dans l'utilisation de Alias, changeRep, changeNom. Il faut toujours
tester le code retour

Espérant aider,

Victor

non désolé je n'utilise pas tout cela et en plus je n'écris pas dans le
fichier concerné (lecture uniquement)

--
Cordialement JeAn-PhI

JeAn-PhI wrote:

cela se produit chez plusieurs clients différent après une réindexation
tout rentre dans l'ordre

ce qui est corrompu est le fichier index, qui peut se modifier lui-même
je m'imagine. Lorsqu'il y a un problème avec les fichiers index, il vaut
la peine de vérifier que les caches réseaux et OpLocks des POSTES de
travail (LANMAN Workstation) sont désactivés.

Salutations
Mat

Il se trouve que mat a formulé :

JeAn-PhI wrote:

cela se produit chez plusieurs clients différent après une réindexation
tout rentre dans l'ordre

ce qui est corrompu est le fichier index, qui peut se modifier lui-même je
m'imagine. Lorsqu'il y a un problème avec les fichiers index, il vaut la
peine de vérifier que les caches réseaux et OpLocks des POSTES de travail
(LANMAN Workstation) sont désactivés.

Salutations
Mat

j'ai du mal à comprendre comment un fichier d'index peut se modifier
lui même vu que je n'écris jamais dans ce fichier je ne fais que des
lectures pour les oplocks je vais voir pour les caches réseaux je ne
sais pas comment on fait.
ce qui encore plus bizzare c'est que pour tous les fichiers présents il
n'y a que celui-ci qui me pose autant de pb

--
Cordialement JeAn-PhI

Le 05/10/2006, JeAn-PhI a supposé :

Il se trouve que mat a formulé :

JeAn-PhI wrote:

cela se produit chez plusieurs clients différent après une réindexation

....

ce qui encore plus bizzare c'est que pour tous les fichiers présents il n'y a
que celui-ci qui me pose autant de pb

bonjour

petite question : qui et comment écrit-on dans ce fichier ?

titou44 chez freesurf.fr

--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com

Dans son message précédent, titou44 a écrit :

Le 05/10/2006, JeAn-PhI a supposé :

Il se trouve que mat a formulé :

JeAn-PhI wrote:

cela se produit chez plusieurs clients différent après une réindexation

....

ce qui encore plus bizzare c'est que pour tous les fichiers présents il n'y
a que celui-ci qui me pose autant de pb

bonjour

petite question : qui et comment écrit-on dans ce fichier ?

titou44 chez freesurf.fr

par moi même et il est livré avec l'application et il a été créé il y a
plus de 1 an

--
Cordialement JeAn-PhI