erreurs 26 ou 2066 occasionnelles sur divers fichiers de donnéesRésolu

Question

Bonjour,

j'ai repris depuis plus d'1 an une application VFP6 qui utilise une multitude de tables avec index structurel : fichiers DBF avec CDX du même nom associé (+ parfois un fichier FPT pour les mémos). J'avais déjà échangé avec MichelAtoutFox sur le sujet "erreur 26 lors de l'ouverture de fichiers de données", ce sujet n'a jamais vraiment été solutionné chez le client qui avait le problème de fichiers CDX qui disparaissent. La cause du phénomène n'a pas été identifiée (antivirus ?), j'ai contourné ce problème en régénérant automatiquement au lancement de mon programme les quelques fichiers qui n'existent parfois pas chez ce client.

J'ai depuis ce temps recompilé tous les programmes avec VFP9, même si ces nouvelles versions VFP9 ne sont pas encore installées chez tous les clients. Régulièrement, les utilisateurs (ceux qui ont les programmes VFP6 et aussi ceux qui ont les programmes VFP9) me signalent des erreurs 26 ou 2066 concernant diverses tables (rarement les mêmes).

Je ne sais pas si c'est l'application elle-même qui genère ces problèmes d'index (notamment par l'utilisation de nombreux alias sur des fichiers DBF en variables globales), ou si c'est une cause extérieure. Difficile de connaitre et reproduire l'origine de ce genre de problèmes, mais le résultat est que l'application semble structurellement instable en utilisation intensive.

N'étant pas expert FoxPro, je me demande si ce genre de problèmes arrive souvent avec des programmes FoxPro ou si mon application est un cas isolé.
Est-ce qu'une bonne pratique du développement FoxPro est de prévoir dans l'appli une régénération systématique des index en cas d'erreurs de ce type lors de chaque ouverture d'un fichier DBF ? Cela peut alors engendrer des temps de traitement très longs s'il y a beaucoup de données !
La quantité importante de fichiers DBF/CDX/FPT de mon application est-elle une partie de la cause de ces phénomènes ? Il semblerait notamment qu'un ratio nombre de fichiers / taille du répertoire très grand puisse être détecté comme problématique par certains antivirus, mais peut-être est-ce déjà problématique pour FoxPro lui-même ? (est-il conseillé de plutôt regrouper les tables dans un seul fichier DBC ?)

Merci de tout retour d'expérience.

michelatoutfox · Accepted Answer

Effectivement, si tu ne peux pas intervenir sur le client pour demander que [list][*] toute la connectique (switches, routeurs, etc) soit en alimentation sans rupture
[*] les répertoires des données et tous les types de fichiers associés à VFP soit exclus de l'antivirus 
/list alors, dans ces conditions, il ne te reste que l'utilitaire de réindexation.
Quant à la fermeture violente, un petit "mouchard" est facile à écrire, qui te permet de vérivier qu'on est sorti proprement de l'application. Disons que ça facilite les discussions ultérieures avec le client, quand tu peux prouver que ses problèmes proviennent d'une mauvaise utilisation du système.

michelatoutfox · Answer

Erreur 26 ou 2066? ce n'est pas du tout la même ereur!
la 2066 signale une corruption d'index. 
on en a déjà discuté: les causes possibles sont l'antivirus, les ruptures réseau, les pb de disque. les solutions paliatives sont les utilitaires de réindexation, les solutions proactives sont la bonne gestion de l'antivirus, l'alimenattion ondulée des switches et routeurs (et le conrole des cartes réseau), la vérification des caches disques.

l'erreur 26 signale une erreur de code. il manque un index nécessaire pour une opération update, seek, find, ou set relation.

dans les 2 cas, le nombre de fichiers n'a aucune incidence, la taille du répertoire non plus (pour autant que tout ça reste dans les limites de l'OS et dans les limites de VFP définies clairement dans l'aide). Référencer les tables dans un dbc est intéressant, mais n'a rien à voir avec ce problème.

un fichier cdx ne disparait pas spontanément: il peut être "flambé" (passer à 0 octets) en cas de pb réseau, mais il ne disparait que si quelque part on le demande. son nom est inscrit dans la FAT quand on le crée, il faut explicitement le supprimer pour enlever ce nom de la FAT.

stepber · Answer

Merci de cette réponse rapide.

Un exemple concret : un utilisateur chez qui l'antivirus a été désactivé pendant une phase de tests a obtenu tout de même une erreur 2066. Il n'y a visiblement pas eu d'erreur préalable de l'application ou de plantage mais, même en utilisant des onduleurs, difficile d'être certain qu'il n'y a pas de fermeture violente.
Dans ce cas, la seule solution est de passer par un utilitaire de réindexation avant de relancer l'application ? Ça peut légitimement sembler un peu lourd pour l'utilisateur...

Pour les cas d'erreur 26, ils sont en général liés à la disparition d'un fichier CDX. Comme déjà évoqué, on peut l'attribuer à un passage à 0 octets du fichier suite à un plantage, fichier alors supprimé par un utilitaire de type antivirus. Personnellement, je n'ai jamais reproduit ce phénomène en tests et je peux difficilement interdire aux utilisateurs leur antivirus sur les répertoires de l'application FoxPro. Comme évoqué ci-dessus, j'ai donc contourné ce problème en régénérant automatiquement au lancement de mon programme les quelques fichiers CDX qui n'existent parfois pas chez ce client. C'est donc visiblement la seule solution ne requérant pas d'intervention de l'utilisateur.

stepber · Answer

J'avais déjà ajouté des traces dans un fichier de LOG pour détecter les sorties anormales de l'application. Hélas, dans mon cas d'erreur 2066, la sortie précédente de l'application était normale et en plus l'antivirus était désactivé. Donc pas d'explication, ce qui est toujours inquiétant pour l'utilisateur (et pour moi).
J'en profite pour clôturer aussi le précédent thème sur l'erreur 26, puisqu'il a en plus dérivé sur un autre sujet par la suite. 
Merci Michel pour toutes ces explications. Je ne manquerai pas de poster si j'ai du nouveau sur ces sujets.

Erreurs 26 ou 2066 occasionnelles sur divers fichiers de données

4 réponses

Votre réponse

Discussions similaires