erreur 26 lors de l'ouverture de fichiers de données

Bonjour,

je reprends actuellement un logiciel développé avec VFP6.

Une instruction d'ouverture de table FoxPro dans le programme provoque de temps en temps une erreur "26 - La table n'a aucun ordre d'index actif." chez un utilisateur. La partie de programme concernée, et donc cette instruction, est exécutée de très nombreuses fois dans le logiciel sans générer d'erreur. Par contre, lorsqu'une erreur 26 s'est produite, il devient impossible d'ouvrir la table (fichier DBF) concernée sans faire au préalable une réindexation. Cette erreur n'est pas reproductible systématiquement et se produit par exemple assez fréquemment sur l'instruction "use ..." de l'exemple ci-dessous. Cette erreur se produit aussi sur d'autres instructions "use ..." du logiciel.

 nom_fichier = chemincomplet + "dq_prg\DQCM_TRV"
 IF !USED("SSDET_DQCM")
    use (nom_fichier) in 0 order 1 alias SSDET_DQCM shared again
 ENDIF
 select SSDET_DQCM
 ...

Je suppose donc que les indexes définis sur la table sont détruits ou altérés lorsque l'erreur se produit, mais il ne semble pas y avoir d'instructions qui pourraient expliquer cela ailleurs dans le logiciel.

Etant débutant sur FoxPro, tout avis ou piste d'enquête est bienvenu...

Merci d'avance

Bonjour,

l'erreur 26 est provoquée par la partie "ORDER 1" de ta clause use.
Peux-tu nous dire comment sont créés ces index, et en particulier s'il s'agit :
- d'index structurel condensé (matable.cdx, avec le nom de l'index identique à celui de la table),
- d'index structurel non condensé (monfichier.cdx, le nom est différent de celui de la table),
- ou d'index "ordinaires" (monfichier.idx)

Dans tous les cas, méfie-toi comme de la peste de l'adressage des tag d'index par leur numéro: use matable ... order 1 est à proscrire, il faut lui préférer use matable...order <NomDuTag>.

Merci pour la rapidité de cette réponse.

Les index associés aux tables concernées par mes problèmes se trouvent toujours dans un fichier CDX du même nom que le fichier DBF contenant les données (par exemple, dans le cas cité, la table s'appelle DQCM_TRV.DBF et le fichier d'index s'appelle DQCM_TRV.CDX).

J'ai du mal à saisir la différence, hormis une plus grande clarté du code, entre "use matable ... order 1" et "use matable...order <NomDuTag>" : y a t'il un risque de perte de l'association entre le nom d'un index et son numéro ? Est-ce à cause du fait que le numéro d'index réprésente son rang dans l'ordre de création des index ? 

L'utilisation du nom de l'index n°1 à la place du numéro dans mon "...order 1" pourrait-elle suffire à m'éviter l'erreur 26 qui se produit parfois ?
Si je suis la documentation, la syntaxe à utiliser en remplacement serait donc probablement "... order tag <nom donné à l'index>", mais je ne suis visiblement pas obligé de rajouter la clause "index DQCM_TRV.CDX" puisque le fichier CDX porte le même nom que mon fichier DBF.

1) "... order 1"
Il s'agit d'une fonctionalité qui n'est destinée qu'à assurer la comptaibilité avec les versions très antérieures.
l'utilisation de "... order 1" est risquée parceque les numéro d'index peuvent être modifiés sans que tu le saches: cette numérotation est interne à VFP, et il vaut mieux maitriser les choses en utilisant le nom du tag d'index.

2) ton fichier d'index est bien du type cdx structurel, il ne faut surtout pas spécifier de nom de fichier d'index après la clause ... order tag <nomTag>

3) quelle est la structure de cette table, et quelle est l'expression de cet index 1?

Es-tu ABSOLUMENT certain que ce soit cette instruction "use..." qui déclenche l'erreur? tu as un gestionnaire d'erreur qui enregistre la ligne qui provoque l'erreur, tu as vu cette ligne en erreur en débogage?

je rechercherais plutot du coté d'un SEEK (ou une de ses variantes)

Merci pour ces explications : effectivement je comprends qu'il vaut mieux utiliser le nom d'index qu'un numéro mais, comme évoqué, je reprends un logiciel en VFP6 et toutes les ouvertures de fichiers sont effectuées en utilisant le numéro de l'index et non son nom donc je modifierai ça progressivement dans le logiciel.

En effet, j'ai une gestion d'erreur qui affiche un message d'erreur personnalisé et écrit dans un log notamment les informations retournées par les fonctions FoxPro program() et lineno(), ce qui m'a permis de localiser la ligne de code en cause et ainsi de voir que ces erreurs 26 se produisent toujours sur une instruction "use..." (parfois sur d'autres instructions "use..." que mon exemple). Pour en être bien certain car en consultant l'aide j'ai vu que cette erreur survenait effectivement plutôt sur des instructions de type SEEK, j'écris aussi dans le même log des phrases de texte uniques juste avant et juste après l'instruction "use..." de mon exemple, et j'ai pu donc visualiser récemment qu'une erreur 26 s'est bien produite chez l'utilisateur sur la ligne de code "use...order 1..." en récupérant son log.

Un de mes gros soucis est que, précisément, je n'ai personnellement jamais réussi à reproduire cette erreur en débogage, mais je vais bientôt récupérer les données que l'utilisateur a sauvegardées lorsque la dernière erreur 26 est survenue chez lui (notamment ses fichiers DQCM_TRV.DBF et DQCM_TRV.CDX) : j'espère qu'en utilisant ces données je reproduirais enfin l'erreur en débogage !
Cependant, même en cas de reproduction de l'erreur, je ne suis pas certain de trouver une explication, à moins que le remplacement de "... order 1" par "... order tag <nom de l'index>" dans l'instruction d'ouverture ne suffise à éviter le problème...

Comme demandé, voici un résumé de la structure de la table DQCM_TRV en cause dans mon exemple :
domaine               caractère      2
item_dom             caractère      3
topologie              caractère    20
ordre_art              numérique    4      0
article                   caractère    23
cd_compo            caractère    20
...
ordre                    numérique    4      0
...

Il y a 24 index définis sur cette table, le 1er qui doit être celui à utiliser est défini ainsi :
ordre : croissant
nom : DQCM_TRV01 (c'est donc ce nom que je compte utiliser à la place du 1 dans "use...order tag DQCM_TRV01...")
type : régulier
expression : article+cd_compo+STR(ordre,4)
filtre : vide

Questions complémentaires:
les tables sont-elles sur la machine sur laquelle l'erreur se produit, ou bien sur un poste réseau?
la table qui pose problème est-elle rattachée à un dbc, ou s'agit-il d'une table libre?

Les tables sont sur une machine distante accessible par le réseau local, tout comme les programmes compilés qui sont lancés par un raccourci depuis le poste de l'utilisateur qui a les erreurs.
Je précise que c'est la configuration type chez quasiment tous les autres utilisateurs finaux du logiciel qui n'ont jamais l'erreur 26.

Aucune des tables sur lesquelles une erreur 26 se produit parfois lors d'un "use..." n'est rattachée à un DBC.

Ah, ton problème est intéressant!
quelques hypothèses et pistes de recherche:

- Est-ce que tu as quelque part un bout de code qui réindexerait ce fichier? on pourrait alors imaginer que cette réindexation ne soit pas correctement effectuée et que ton erreur 26 survienne après la réindexation

- peux-tu vérifier l'existence éventuelle d'autres fichiers DQCM_TRV.CDX qui serait accessible à cet utilisateur? si un tel fichier existe, et qu'il s'agit d'une version qui n'aurait pas ce tag, alors on pourrait envisager une erreur

- et enfin, si l'erreur se produit sur un seul poste, alors on doit regarder du coté de la config matérielle: en premier lieu toute la connectivité réseau pour ce poste, en 2ème lieu la RAM

Il existe effectivement une fonctionnalité qui réindexe de nombreux fichiers dont DQCM_TRV. Mais, au contraire, cette fonctionnalité permet visiblement de remettre en bon état les index du fichier suite à une erreur 26, puisque c'est en fait la seule solution pour les utilisateurs du logiciel de ne plus avoir l'erreur 26 systématiquement lorsqu'elle s'est produit une fois.

En effet, l'erreur 26 est déjà survenue sur plusieurs postes chez le client concerné, donc ne semble pas liée à des spécificités matérielles. Lorsque l'erreur s'est produit une fois, plus personne ne peut lancer la fonction du logiciel qui contient l'instruction "use...order 1..." sans avoir l'erreur 26 (logique puisque c'est le même fichier DQCM_TRV concerné) : le seul moyen de s'en sortir est de faire une réindexation.

Comme évoqué, je vais vérifier s'il existe bien un seul fichier DQCM_TRV.CDX accessible aux utilisateurs chez ce client.

Depuis mon dernier message, j'attends toujours les données que l'utilisateur devait sauvegarder lorsque la dernière erreur 26 est survenue chez lui (notamment ses fichiers DQCM_TRV.DBF et DQCM_TRV.CDX), afin de tenter de reproduire l'erreur 26 en débogage, et de vérifier s'il existe bien un seul fichier DQCM_TRV.CDX accessible aux utilisateurs chez ce client.
Il semblerait que l'erreur ne se soit produite qu'une ou 2 fois en 3 mois et à un moment où personne n'était en mesure de copier ces données, donc le sujet est toujours en stand-by. Je ne manquerai pas de poster un message dès que j'ai du nouveau...