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)
Salut,
J'ai bien compris, mais ce que j'ai voulu dire c'est que peut être, à travers un Alias ou par le fait que le nom de ton fichier se trouve dans une variable, tu écris dedans alors que tu penses être ailleurs.
Autre chose : en protégeant le fichier en écriture, peut être qu'on saura un jour que c'est un petit malin qui recopie mal ou un batch de sauvegarde-restauration qui marche mal. Qui sait... ou encore mise à jour automatique de programmes livrée avec des fichiers de données, qui écrase les données et pas l'index parce que déjà ouvert.
En dehors de ça, je vois pas. ça m'intrigue. J'aimerais bien savoir...
Victor
"JeAn-PhI" <no.spam@spam.fr> a écrit dans le message de news:
mn.24457d6ab89ec949.49289@spam.fr...
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)
Salut,
J'ai bien compris, mais ce que j'ai voulu dire c'est que peut être, à
travers un Alias ou par le fait que le nom de ton fichier se trouve dans une
variable, tu écris dedans alors que tu penses être ailleurs.
Autre chose : en protégeant le fichier en écriture, peut être qu'on saura un
jour que c'est un petit malin qui recopie mal ou un batch de
sauvegarde-restauration qui marche mal. Qui sait...
ou encore mise à jour automatique de programmes livrée avec des fichiers de
données, qui écrase les données et pas l'index parce que déjà ouvert.
En dehors de ça, je vois pas. ça m'intrigue. J'aimerais bien savoir...
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)
Salut,
J'ai bien compris, mais ce que j'ai voulu dire c'est que peut être, à travers un Alias ou par le fait que le nom de ton fichier se trouve dans une variable, tu écris dedans alors que tu penses être ailleurs.
Autre chose : en protégeant le fichier en écriture, peut être qu'on saura un jour que c'est un petit malin qui recopie mal ou un batch de sauvegarde-restauration qui marche mal. Qui sait... ou encore mise à jour automatique de programmes livrée avec des fichiers de données, qui écrase les données et pas l'index parce que déjà ouvert.
En dehors de ça, je vois pas. ça m'intrigue. J'aimerais bien savoir...
Victor
mat
JeAn-PhI wrote:
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
Je me suis mal exprimé. Je pense HF peut décider de re-indexer un fichier dans certains cas, comme le font d'ailleurs d'autres bases de données.
De toute façon, si tout est ok après une ré-indexation, alors c'est bien le fichier index qui avait été corrompu sinon la ré-indexation ne sert à rien.
Salutations Mat
JeAn-PhI wrote:
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
Je me suis mal exprimé. Je pense HF peut décider de re-indexer un
fichier dans certains cas, comme le font d'ailleurs d'autres bases de
données.
De toute façon, si tout est ok après une ré-indexation, alors c'est bien
le fichier index qui avait été corrompu sinon la ré-indexation ne sert à
rien.
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
Je me suis mal exprimé. Je pense HF peut décider de re-indexer un fichier dans certains cas, comme le font d'ailleurs d'autres bases de données.
De toute façon, si tout est ok après une ré-indexation, alors c'est bien le fichier index qui avait été corrompu sinon la ré-indexation ne sert à rien.
Salutations Mat
mat
mat wrote: ...
Je me suis mal exprimé. Je pense HF peut décider de re-indexer un fichier dans certains cas,
description du projet, onglet Fichiers.
mat wrote:
...
Je me suis mal exprimé. Je pense HF peut décider de re-indexer un
fichier dans certains cas,
Je me suis mal exprimé. Je pense HF peut décider de re-indexer un fichier dans certains cas,
description du projet, onglet Fichiers.
Val
Bonjour JeAn-PhI,
"JeAn-PhI" a écrit dans le message de news:
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
-- Cordialement JeAn-PhI
Dans l'attente que tu trouves la cause de ce phénomène (car il y a assurément quelque chose qui coince quelque part) et si c'est une corruption de l'index et si le fichier est un fichier Hyper File 7, alors tu peux éventuellement bricoler quelque chose pour qu'il ne se produise pas.
Pour ce faire: 1) tu actives la ré-indexation automatique dans la description du projet 2) tu modifies le programme, de façon à ce que le fichier HF soit immédiatement fermé après son utilisation et ceci via Hferme(nomfichier) 3) après l'instruction de fermeture du fichier, tu supprimes le fichier .NDX via un fSupprime
Voilà. Ainsi, à chaque fois que le fichier doit être lu, l'index est re-créé automatiquement. Ensuite, à chaque fois que le fichier est fermé, l'index est supprimé automatiquement. Donc, en théorie, l'index ne devrait jamais être corrompu (à moins bien sur que le quelque chose d'anormal se produise pendant la phase de lecture)
A+
Val
Bonjour JeAn-PhI,
"JeAn-PhI" <no.spam@spam.fr> a écrit dans le message de news:
mn.1c3e7d6a6c3e882b.49289@spam.fr...
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
--
Cordialement JeAn-PhI
Dans l'attente que tu trouves la cause de ce phénomène (car il y a
assurément quelque chose qui coince quelque part) et si c'est une corruption
de l'index et si le fichier est un fichier Hyper File 7, alors tu peux
éventuellement bricoler quelque chose pour qu'il ne se produise pas.
Pour ce faire:
1) tu actives la ré-indexation automatique dans la description du projet
2) tu modifies le programme, de façon à ce que le fichier HF soit
immédiatement fermé après son utilisation et ceci via Hferme(nomfichier)
3) après l'instruction de fermeture du fichier, tu supprimes le fichier .NDX
via un fSupprime
Voilà.
Ainsi, à chaque fois que le fichier doit être lu, l'index est re-créé
automatiquement.
Ensuite, à chaque fois que le fichier est fermé, l'index est supprimé
automatiquement.
Donc, en théorie, l'index ne devrait jamais être corrompu (à moins bien sur
que le quelque chose d'anormal se produise pendant la phase de lecture)
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
-- Cordialement JeAn-PhI
Dans l'attente que tu trouves la cause de ce phénomène (car il y a assurément quelque chose qui coince quelque part) et si c'est une corruption de l'index et si le fichier est un fichier Hyper File 7, alors tu peux éventuellement bricoler quelque chose pour qu'il ne se produise pas.
Pour ce faire: 1) tu actives la ré-indexation automatique dans la description du projet 2) tu modifies le programme, de façon à ce que le fichier HF soit immédiatement fermé après son utilisation et ceci via Hferme(nomfichier) 3) après l'instruction de fermeture du fichier, tu supprimes le fichier .NDX via un fSupprime
Voilà. Ainsi, à chaque fois que le fichier doit être lu, l'index est re-créé automatiquement. Ensuite, à chaque fois que le fichier est fermé, l'index est supprimé automatiquement. Donc, en théorie, l'index ne devrait jamais être corrompu (à moins bien sur que le quelque chose d'anormal se produise pendant la phase de lecture)
A+
Val
JeAn-PhI
Val avait prétendu :
Bonjour JeAn-PhI,
"JeAn-PhI" a écrit dans le message de news:
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
-- Cordialement JeAn-PhI
Dans l'attente que tu trouves la cause de ce phénomène (car il y a assurément quelque chose qui coince quelque part) et si c'est une corruption de l'index et si le fichier est un fichier Hyper File 7, alors tu peux éventuellement bricoler quelque chose pour qu'il ne se produise pas.
Pour ce faire: 1) tu actives la ré-indexation automatique dans la description du projet 2) tu modifies le programme, de façon à ce que le fichier HF soit immédiatement fermé après son utilisation et ceci via Hferme(nomfichier) 3) après l'instruction de fermeture du fichier, tu supprimes le fichier .NDX via un fSupprime
Voilà. Ainsi, à chaque fois que le fichier doit être lu, l'index est re-créé automatiquement. Ensuite, à chaque fois que le fichier est fermé, l'index est supprimé automatiquement. Donc, en théorie, l'index ne devrait jamais être corrompu (à moins bien sur que le quelque chose d'anormal se produise pendant la phase de lecture)
A+
Val
c'est pas bête comme idée je vais essayer d'abord de femrer le fichier après chaque lecture pour voir puis si cela ne fonctionne toujours pas je passerais à ta solution merci
-- Cordialement JeAn-PhI
Val avait prétendu :
Bonjour JeAn-PhI,
"JeAn-PhI" <no.spam@spam.fr> a écrit dans le message de news:
mn.1c3e7d6a6c3e882b.49289@spam.fr...
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
-- Cordialement JeAn-PhI
Dans l'attente que tu trouves la cause de ce phénomène (car il y a
assurément quelque chose qui coince quelque part) et si c'est une corruption
de l'index et si le fichier est un fichier Hyper File 7, alors tu peux
éventuellement bricoler quelque chose pour qu'il ne se produise pas.
Pour ce faire:
1) tu actives la ré-indexation automatique dans la description du projet
2) tu modifies le programme, de façon à ce que le fichier HF soit
immédiatement fermé après son utilisation et ceci via Hferme(nomfichier)
3) après l'instruction de fermeture du fichier, tu supprimes le fichier .NDX
via un fSupprime
Voilà.
Ainsi, à chaque fois que le fichier doit être lu, l'index est re-créé
automatiquement.
Ensuite, à chaque fois que le fichier est fermé, l'index est supprimé
automatiquement.
Donc, en théorie, l'index ne devrait jamais être corrompu (à moins bien sur
que le quelque chose d'anormal se produise pendant la phase de lecture)
A+
Val
c'est pas bête comme idée je vais essayer d'abord de femrer le fichier
après chaque lecture pour voir puis si cela ne fonctionne toujours pas
je passerais à ta solution
merci
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
-- Cordialement JeAn-PhI
Dans l'attente que tu trouves la cause de ce phénomène (car il y a assurément quelque chose qui coince quelque part) et si c'est une corruption de l'index et si le fichier est un fichier Hyper File 7, alors tu peux éventuellement bricoler quelque chose pour qu'il ne se produise pas.
Pour ce faire: 1) tu actives la ré-indexation automatique dans la description du projet 2) tu modifies le programme, de façon à ce que le fichier HF soit immédiatement fermé après son utilisation et ceci via Hferme(nomfichier) 3) après l'instruction de fermeture du fichier, tu supprimes le fichier .NDX via un fSupprime
Voilà. Ainsi, à chaque fois que le fichier doit être lu, l'index est re-créé automatiquement. Ensuite, à chaque fois que le fichier est fermé, l'index est supprimé automatiquement. Donc, en théorie, l'index ne devrait jamais être corrompu (à moins bien sur que le quelque chose d'anormal se produise pendant la phase de lecture)
A+
Val
c'est pas bête comme idée je vais essayer d'abord de femrer le fichier après chaque lecture pour voir puis si cela ne fonctionne toujours pas je passerais à ta solution merci
-- Cordialement JeAn-PhI
mat
JeAn-PhI wrote: ...
je ne fais que des lectures pour les oplocks je vais voir pour les caches réseaux je ne sais pas comment on fait.
...
Voilà comment configurer les machines dans le réseau.
Rien. Pour autant que je sache, c'est comme pour XP et W2K. Attention, seulement changer les clés indiquées de LanmanWorkstation et Rdr. En fait c'est surtout les PC "clients" qui sont en cause, mais évidemment on peut aussi faire tourner une application sur le serveur, donc c'est mieux de modifier la base de registre.
JeAn-PhI wrote:
mat a formulé ce dimanche :
JeAn-PhI wrote:
...
je ne fais que des lectures pour les oplocks je vais voir pour les
caches réseaux je ne sais pas comment on fait.
...
Voilà comment configurer les machines dans le réseau.
Rien. Pour autant que je sache, c'est comme pour XP et W2K. Attention,
seulement changer les clés indiquées de LanmanWorkstation et Rdr. En
fait c'est surtout les PC "clients" qui sont en cause, mais évidemment
on peut aussi faire tourner une application sur le serveur, donc c'est
mieux de modifier la base de registre.
Rien. Pour autant que je sache, c'est comme pour XP et W2K. Attention, seulement changer les clés indiquées de LanmanWorkstation et Rdr. En fait c'est surtout les PC "clients" qui sont en cause, mais évidemment on peut aussi faire tourner une application sur le serveur, donc c'est mieux de modifier la base de registre.
JeAn-PhI
Le 09/10/2006, mat a supposé :
JeAn-PhI wrote:
mat a formulé ce dimanche :
JeAn-PhI wrote: ...
je ne fais que des lectures pour les oplocks je vais voir pour les caches réseaux je ne sais pas comment on fait.
...
Voilà comment configurer les machines dans le réseau.
Rien. Pour autant que je sache, c'est comme pour XP et W2K. Attention, seulement changer les clés indiquées de LanmanWorkstation et Rdr. En fait c'est surtout les PC "clients" qui sont en cause, mais évidemment on peut aussi faire tourner une application sur le serveur, donc c'est mieux de modifier la base de registre.
non je n'ai pas l'appli sur le serveur seulement les données merci
-- Cordialement JeAn-PhI
Le 09/10/2006, mat a supposé :
JeAn-PhI wrote:
mat a formulé ce dimanche :
JeAn-PhI wrote:
...
je ne fais que des lectures pour les oplocks je vais voir pour les caches
réseaux je ne sais pas comment on fait.
...
Voilà comment configurer les machines dans le réseau.
Rien. Pour autant que je sache, c'est comme pour XP et W2K. Attention,
seulement changer les clés indiquées de LanmanWorkstation et Rdr. En fait
c'est surtout les PC "clients" qui sont en cause, mais évidemment on peut
aussi faire tourner une application sur le serveur, donc c'est mieux de
modifier la base de registre.
non je n'ai pas l'appli sur le serveur seulement les données
merci
Rien. Pour autant que je sache, c'est comme pour XP et W2K. Attention, seulement changer les clés indiquées de LanmanWorkstation et Rdr. En fait c'est surtout les PC "clients" qui sont en cause, mais évidemment on peut aussi faire tourner une application sur le serveur, donc c'est mieux de modifier la base de registre.
non je n'ai pas l'appli sur le serveur seulement les données merci
