Sur deux appli (une wd8, l'autre en wd10), avec deux analyse completement
différente, j'observe le meme symptome :
lors de la purge annuelle de quelques milliers de lignes, ca rame grave
j'observe ce phénomène uniquement sur des gros fichiers avec des grosses
fiches.
exemple 1:
58000 enregistrement à supprimer dans un fichier d'une taille totale 43mo:
temps de suppression 35 minutes (27 / s)
exemple 2: (en mode transaction)
2826 enregistrement à supprimer dans un fichier d'une taille totale 700Mo
temps de suppression 3 mn (15/s)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
patrice
J'ai oublié de préciser : - pendant ce temps, le cpu n'est pas occupé du tout (oscille entre 0 et 20) - c'est de l'hyperfile classique
"patrice" a écrit dans le message de news:456726db$0$6263$
Bonjour
Sur deux appli (une wd8, l'autre en wd10), avec deux analyse completement différente, j'observe le meme symptome : lors de la purge annuelle de quelques milliers de lignes, ca rame grave j'observe ce phénomène uniquement sur des gros fichiers avec des grosses fiches.
exemple 1: 58000 enregistrement à supprimer dans un fichier d'une taille totale 43mo: temps de suppression 35 minutes (27 / s)
exemple 2: (en mode transaction) 2826 enregistrement à supprimer dans un fichier d'une taille totale 700Mo temps de suppression 3 mn (15/s)
vous trouvez pas ca un peu lent ??
J'ai oublié de préciser :
- pendant ce temps, le cpu n'est pas occupé du tout (oscille entre 0 et 20)
- c'est de l'hyperfile classique
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news:456726db$0$6263$426a74cc@news.free.fr...
Bonjour
Sur deux appli (une wd8, l'autre en wd10), avec deux analyse completement
différente, j'observe le meme symptome :
lors de la purge annuelle de quelques milliers de lignes, ca rame grave
j'observe ce phénomène uniquement sur des gros fichiers avec des grosses
fiches.
exemple 1:
58000 enregistrement à supprimer dans un fichier d'une taille totale 43mo:
temps de suppression 35 minutes (27 / s)
exemple 2: (en mode transaction)
2826 enregistrement à supprimer dans un fichier d'une taille totale 700Mo
temps de suppression 3 mn (15/s)
J'ai oublié de préciser : - pendant ce temps, le cpu n'est pas occupé du tout (oscille entre 0 et 20) - c'est de l'hyperfile classique
"patrice" a écrit dans le message de news:456726db$0$6263$
Bonjour
Sur deux appli (une wd8, l'autre en wd10), avec deux analyse completement différente, j'observe le meme symptome : lors de la purge annuelle de quelques milliers de lignes, ca rame grave j'observe ce phénomène uniquement sur des gros fichiers avec des grosses fiches.
exemple 1: 58000 enregistrement à supprimer dans un fichier d'une taille totale 43mo: temps de suppression 35 minutes (27 / s)
exemple 2: (en mode transaction) 2826 enregistrement à supprimer dans un fichier d'une taille totale 700Mo temps de suppression 3 mn (15/s)
vous trouvez pas ca un peu lent ??
VPSoft
Bonsoir,
Ca PEUT "paraître long" mais être normal, dans le contexte HF (sans faire de comparaisons avec d'autres bases, puisque ce n'est pas la question).
La durée dépend de beaucoup de facteurs, dont : - les temps d'accès au disque, le fait que l'écriture soit différée ou pas, mais surtout : - Nombre d'index dans le fichier (plus il y en a, plus il y a des mises à jour du .ndx à faire) - Le fait de devoir lire tous les enregs et tester s'il faut supprimer ou pas (ou par filtre, ce qui revient au même)
A mon avis, il faut voir si possible utiliser un des index existant pour réduire le nombre d'enregistrements à lire/supprimer. Autre possibilité : Lire / supprimer sans utiliser les index et réindexer à la fin. Autre chose : éviter affichage des enregistrements traités ou autres jauges. Vérifier si pas instruction "Multitache" dans la boucle.
Dans un traitement équivalent, je fais le contraire car il y a plus d'enreg à supprimer qu'à conserver : je copie dans un alias les enreg à garder, je supprime le fichier et je renomme l'alias.
Espérant avoir aidé,
Victor
"patrice" a écrit dans le message de news: 456726db$0$6263$
Bonjour
Sur deux appli (une wd8, l'autre en wd10), avec deux analyse completement différente, j'observe le meme symptome : lors de la purge annuelle de quelques milliers de lignes, ca rame grave j'observe ce phénomène uniquement sur des gros fichiers avec des grosses fiches.
exemple 1: 58000 enregistrement à supprimer dans un fichier d'une taille totale 43mo: temps de suppression 35 minutes (27 / s)
exemple 2: (en mode transaction) 2826 enregistrement à supprimer dans un fichier d'une taille totale 700Mo temps de suppression 3 mn (15/s)
vous trouvez pas ca un peu lent ??
Bonsoir,
Ca PEUT "paraître long" mais être normal, dans le contexte HF (sans faire de
comparaisons avec d'autres bases, puisque ce n'est pas la question).
La durée dépend de beaucoup de facteurs, dont :
- les temps d'accès au disque, le fait que l'écriture soit différée ou pas,
mais surtout :
- Nombre d'index dans le fichier (plus il y en a, plus il y a des mises à
jour du .ndx à faire)
- Le fait de devoir lire tous les enregs et tester s'il faut supprimer ou
pas (ou par filtre, ce qui revient au même)
A mon avis, il faut voir si possible utiliser un des index existant pour
réduire le nombre d'enregistrements à lire/supprimer.
Autre possibilité : Lire / supprimer sans utiliser les index et réindexer à
la fin.
Autre chose : éviter affichage des enregistrements traités ou autres jauges.
Vérifier si pas instruction "Multitache" dans la boucle.
Dans un traitement équivalent, je fais le contraire car il y a plus d'enreg
à supprimer qu'à conserver : je copie dans un alias les enreg à garder, je
supprime le fichier et je renomme l'alias.
Espérant avoir aidé,
Victor
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news: 456726db$0$6263$426a74cc@news.free.fr...
Bonjour
Sur deux appli (une wd8, l'autre en wd10), avec deux analyse completement
différente, j'observe le meme symptome :
lors de la purge annuelle de quelques milliers de lignes, ca rame grave
j'observe ce phénomène uniquement sur des gros fichiers avec des grosses
fiches.
exemple 1:
58000 enregistrement à supprimer dans un fichier d'une taille totale 43mo:
temps de suppression 35 minutes (27 / s)
exemple 2: (en mode transaction)
2826 enregistrement à supprimer dans un fichier d'une taille totale 700Mo
temps de suppression 3 mn (15/s)
Ca PEUT "paraître long" mais être normal, dans le contexte HF (sans faire de comparaisons avec d'autres bases, puisque ce n'est pas la question).
La durée dépend de beaucoup de facteurs, dont : - les temps d'accès au disque, le fait que l'écriture soit différée ou pas, mais surtout : - Nombre d'index dans le fichier (plus il y en a, plus il y a des mises à jour du .ndx à faire) - Le fait de devoir lire tous les enregs et tester s'il faut supprimer ou pas (ou par filtre, ce qui revient au même)
A mon avis, il faut voir si possible utiliser un des index existant pour réduire le nombre d'enregistrements à lire/supprimer. Autre possibilité : Lire / supprimer sans utiliser les index et réindexer à la fin. Autre chose : éviter affichage des enregistrements traités ou autres jauges. Vérifier si pas instruction "Multitache" dans la boucle.
Dans un traitement équivalent, je fais le contraire car il y a plus d'enreg à supprimer qu'à conserver : je copie dans un alias les enreg à garder, je supprime le fichier et je renomme l'alias.
Espérant avoir aidé,
Victor
"patrice" a écrit dans le message de news: 456726db$0$6263$
Bonjour
Sur deux appli (une wd8, l'autre en wd10), avec deux analyse completement différente, j'observe le meme symptome : lors de la purge annuelle de quelques milliers de lignes, ca rame grave j'observe ce phénomène uniquement sur des gros fichiers avec des grosses fiches.
exemple 1: 58000 enregistrement à supprimer dans un fichier d'une taille totale 43mo: temps de suppression 35 minutes (27 / s)
exemple 2: (en mode transaction) 2826 enregistrement à supprimer dans un fichier d'une taille totale 700Mo temps de suppression 3 mn (15/s)
vous trouvez pas ca un peu lent ??
Réal Phil
Oui je trouve ça lent. Moi, je trouverais cette lenteur innacceptable et je ferais plusieurs expériences pour tenter d'accélérer le processus.
Les idées suggérées par Victor sont très pertinentes et valent la peine d'être essayées.
Voici une autre idée à essayer juste pour voir... Sans aucun filtre actif ni aucun index sollicité, faire un simple scan du fichier HF en utilisant POUR TOUT si la version le permet et faire les annulations selon les critères choisis.
Ça devient alors une lecture "séquentielle" et (je présume) les enregistrements annulés ne sont pas tout de suite mis à jour dans l'index. Cette opération devrait donc se faire dans un minimum de temps.
Et à la toute fin, fermer le fichier, effacer le fichier .ndx et reindexer le tout avec le paramètre hNdxCompactage.
Je serais bien curieux de voir la performance de cet essai.
Oui je trouve ça lent. Moi, je trouverais cette lenteur innacceptable
et je ferais plusieurs expériences pour tenter d'accélérer le
processus.
Les idées suggérées par Victor sont très pertinentes et valent la
peine d'être essayées.
Voici une autre idée à essayer juste pour voir...
Sans aucun filtre actif ni aucun index sollicité, faire un simple scan
du fichier HF en utilisant POUR TOUT si la version le permet et faire
les annulations selon les critères choisis.
Ça devient alors une lecture "séquentielle" et (je présume) les
enregistrements annulés ne sont pas tout de suite mis à jour dans
l'index. Cette opération devrait donc se faire dans un minimum de
temps.
Et à la toute fin, fermer le fichier, effacer le fichier .ndx et
reindexer le tout avec le paramètre hNdxCompactage.
Je serais bien curieux de voir la performance de cet essai.
Oui je trouve ça lent. Moi, je trouverais cette lenteur innacceptable et je ferais plusieurs expériences pour tenter d'accélérer le processus.
Les idées suggérées par Victor sont très pertinentes et valent la peine d'être essayées.
Voici une autre idée à essayer juste pour voir... Sans aucun filtre actif ni aucun index sollicité, faire un simple scan du fichier HF en utilisant POUR TOUT si la version le permet et faire les annulations selon les critères choisis.
Ça devient alors une lecture "séquentielle" et (je présume) les enregistrements annulés ne sont pas tout de suite mis à jour dans l'index. Cette opération devrait donc se faire dans un minimum de temps.
Et à la toute fin, fermer le fichier, effacer le fichier .ndx et reindexer le tout avec le paramètre hNdxCompactage.
Je serais bien curieux de voir la performance de cet essai.
patrice
Réal Phil a écrit :
Oui je trouve ça lent. Moi, je trouverais cette lenteur innacceptable et je ferais plusieurs expériences pour tenter d'accélérer le processus.
Les idées suggérées par Victor sont très pertinentes et valent la peine d'être essayées.
Voici une autre idée à essayer juste pour voir... Sans aucun filtre actif ni aucun index sollicité, faire un simple scan du fichier HF en utilisant POUR TOUT si la version le permet et faire les annulations selon les critères choisis.
Ça devient alors une lecture "séquentielle" et (je présume) les enregistrements annulés ne sont pas tout de suite mis à jour dans l'index. Cette opération devrait donc se faire dans un minimum de temps.
Et à la toute fin, fermer le fichier, effacer le fichier .ndx et reindexer le tout avec le paramètre hNdxCompactage.
Je serais bien curieux de voir la performance de cet essai.
j'ai déjà essayé de faire un hlit/recherche pour remplir un tableau des numéros d'enregistrements (ca se fait en 2/3 secondes) puis de supprimer tout les enregistrements, et la, ca rame grave à nouveau.
je pense que ca vient des indexs. cela pourrait être normal, mais le cpu reste désesperemment au repos. ils (pcsoft) doivent faire "autre chose" en meme temps.....
je vais voir s'il est possible de supprimer sans les indexs, mais c'est ma solution de dernier recours car la réindexaton de ce fichier nécessite 40minutes :( (700Mo data, 1.3 go de ndx)
Réal Phil a écrit :
Oui je trouve ça lent. Moi, je trouverais cette lenteur innacceptable
et je ferais plusieurs expériences pour tenter d'accélérer le
processus.
Les idées suggérées par Victor sont très pertinentes et valent la
peine d'être essayées.
Voici une autre idée à essayer juste pour voir...
Sans aucun filtre actif ni aucun index sollicité, faire un simple scan
du fichier HF en utilisant POUR TOUT si la version le permet et faire
les annulations selon les critères choisis.
Ça devient alors une lecture "séquentielle" et (je présume) les
enregistrements annulés ne sont pas tout de suite mis à jour dans
l'index. Cette opération devrait donc se faire dans un minimum de
temps.
Et à la toute fin, fermer le fichier, effacer le fichier .ndx et
reindexer le tout avec le paramètre hNdxCompactage.
Je serais bien curieux de voir la performance de cet essai.
j'ai déjà essayé de faire un hlit/recherche pour remplir un tableau des
numéros d'enregistrements (ca se fait en 2/3 secondes)
puis de supprimer tout les enregistrements, et la, ca rame grave à nouveau.
je pense que ca vient des indexs. cela pourrait être normal, mais le cpu
reste désesperemment au repos.
ils (pcsoft) doivent faire "autre chose" en meme temps.....
je vais voir s'il est possible de supprimer sans les indexs, mais c'est
ma solution de dernier recours car la réindexaton de ce fichier
nécessite 40minutes :( (700Mo data, 1.3 go de ndx)
Oui je trouve ça lent. Moi, je trouverais cette lenteur innacceptable et je ferais plusieurs expériences pour tenter d'accélérer le processus.
Les idées suggérées par Victor sont très pertinentes et valent la peine d'être essayées.
Voici une autre idée à essayer juste pour voir... Sans aucun filtre actif ni aucun index sollicité, faire un simple scan du fichier HF en utilisant POUR TOUT si la version le permet et faire les annulations selon les critères choisis.
Ça devient alors une lecture "séquentielle" et (je présume) les enregistrements annulés ne sont pas tout de suite mis à jour dans l'index. Cette opération devrait donc se faire dans un minimum de temps.
Et à la toute fin, fermer le fichier, effacer le fichier .ndx et reindexer le tout avec le paramètre hNdxCompactage.
Je serais bien curieux de voir la performance de cet essai.
j'ai déjà essayé de faire un hlit/recherche pour remplir un tableau des numéros d'enregistrements (ca se fait en 2/3 secondes) puis de supprimer tout les enregistrements, et la, ca rame grave à nouveau.
je pense que ca vient des indexs. cela pourrait être normal, mais le cpu reste désesperemment au repos. ils (pcsoft) doivent faire "autre chose" en meme temps.....
je vais voir s'il est possible de supprimer sans les indexs, mais c'est ma solution de dernier recours car la réindexaton de ce fichier nécessite 40minutes :( (700Mo data, 1.3 go de ndx)
Réal Phil
Je t'ai envoyé la réponse personnellement par erreur.
Je suggère de tester d'utiliser HRaye à la place de HSupprime. HSupprime fait une opération en plus.
Une fois terminé, fermer le fichier, effacer l'index et faire la reindexation avec HRéindexe(LeFichier, hNdxCompactage).
Ça sauve du temps??
Je t'ai envoyé la réponse personnellement par erreur.
Je suggère de tester d'utiliser HRaye à la place de HSupprime.
HSupprime fait une opération en plus.
Une fois terminé, fermer le fichier, effacer l'index et faire la
reindexation avec
HRéindexe(LeFichier, hNdxCompactage).
Je t'ai envoyé la réponse personnellement par erreur.
Je suggère de tester d'utiliser HRaye à la place de HSupprime. HSupprime fait une opération en plus.
Une fois terminé, fermer le fichier, effacer l'index et faire la reindexation avec HRéindexe(LeFichier, hNdxCompactage).
Ça sauve du temps??
patrice
"Réal Phil" a écrit dans le message de news:
Je suggère de tester d'utiliser HRaye à la place de HSupprime. HSupprime fait une opération en plus.
ca ne change rien du tout, mais cela me semble normal vu que hraye supprime qd les memes les indexs. j'ai vérifié la doc, je vois pas comment supprimer sans utiliser les indexs (j'ai pas trouvé l'équivalent de la fonction hecrit pour la suppression)
"Réal Phil" <realmip@yahoo.ca> a écrit dans le message de
news:1164574729.680163.63250@h54g2000cwb.googlegroups.com...
Je suggère de tester d'utiliser HRaye à la place de HSupprime.
HSupprime fait une opération en plus.
ca ne change rien du tout, mais cela me semble normal vu que hraye supprime
qd les memes les indexs.
j'ai vérifié la doc, je vois pas comment supprimer sans utiliser les indexs
(j'ai pas trouvé l'équivalent de la fonction hecrit pour la suppression)
Je suggère de tester d'utiliser HRaye à la place de HSupprime. HSupprime fait une opération en plus.
ca ne change rien du tout, mais cela me semble normal vu que hraye supprime qd les memes les indexs. j'ai vérifié la doc, je vois pas comment supprimer sans utiliser les indexs (j'ai pas trouvé l'équivalent de la fonction hecrit pour la suppression)
Réal Phil
On 27 nov, 03:55, "patrice" wrote:
"Réal Phil" a écrit dans le message denews:1164574
>Je suggère de tester d'utiliser HRaye à la place de HSupprime. >HSupprime fait une opération en plus.ca ne change rien du tout, mais c ela me semble normal vu que hraye supprime qd les memes les indexs. j'ai vérifié la doc, je vois pas comment supprimer sans utiliser les indexs (j'ai pas trouvé l'équivalent de la fonction hecrit pour la suppressi on)
En effet, je ne l'ai pas trouvé non plus - pour ce langage.
As-tu beaucoup d'index sur ce fichier?
Quel est le nombre habituel de fichiers restant après la purge? Selon la réponse, la technique utilisée peut faire une énorme différence sur le temps.
Remarque que si tu ne trouve pas la solution, au pire, 35 minutes pour un processus fait une fois par année, c'est pas l'idéal mais c'est supportable.
On 27 nov, 03:55, "patrice" <patrice_labracherie_nos...@free.fr> wrote:
"Réal Phil" <real...@yahoo.ca> a écrit dans le message denews:1164574 729.680163.63250@h54g2000cwb.googlegroups.com...
>Je suggère de tester d'utiliser HRaye à la place de HSupprime.
>HSupprime fait une opération en plus.ca ne change rien du tout, mais c ela me semble normal vu que hraye supprime
qd les memes les indexs.
j'ai vérifié la doc, je vois pas comment supprimer sans utiliser les indexs
(j'ai pas trouvé l'équivalent de la fonction hecrit pour la suppressi on)
"Réal Phil" a écrit dans le message denews:1164574
>Je suggère de tester d'utiliser HRaye à la place de HSupprime. >HSupprime fait une opération en plus.ca ne change rien du tout, mais c ela me semble normal vu que hraye supprime qd les memes les indexs. j'ai vérifié la doc, je vois pas comment supprimer sans utiliser les indexs (j'ai pas trouvé l'équivalent de la fonction hecrit pour la suppressi on)
En effet, je ne l'ai pas trouvé non plus - pour ce langage.
As-tu beaucoup d'index sur ce fichier?
Quel est le nombre habituel de fichiers restant après la purge? Selon la réponse, la technique utilisée peut faire une énorme différence sur le temps.
Remarque que si tu ne trouve pas la solution, au pire, 35 minutes pour un processus fait une fois par année, c'est pas l'idéal mais c'est supportable.
VPSoft
Salut,
"patrice" a écrit dans le message de news: 45688780$0$17497$
j'ai déjà essayé de faire un hlit/recherche pour remplir un tableau des numéros d'enregistrements (ca se fait en 2/3 secondes) puis de supprimer tout les enregistrements, et la, ca rame grave à nouveau.
La, je pense qu'il y a un autre problème. Il ne peut pas y avoir une telle différence 2/3 secondes pour obtenir tous les enregs par LitRecherche et 35 Minutes pour les supprimer. - Pas de Trigger après H.supprime ?
D'autre part, d'après ce que tu dis, j'en déduis que tu peux accéder aux enregistrements à supprimer par un index. Donc, est-ce que cet index est utilisé pour la suppression (filtre avec bornes Mini-Maxi)
je pense que ca vient des indexs. cela pourrait être normal, mais le cpu reste désesperemment au repos.
Par contre, le disque s'affole ? (voyant allumé en permanence). Si oui, c'est que tu fais des lectures. Ce serait bon d'avoir le bout de code concerné.
je vais voir s'il est possible de supprimer sans les indexs, mais c'est ma solution de dernier recours car la réindexaton de ce fichier nécessite 40minutes :( (700Mo data, 1.3 go de ndx)
Ca, c'est un signe : Plus que la taille du Ndx, c'est le NOMBRE d'index. Tu dois avoir beaucoup de clés pour chaque enregistrement.
Enfin : J'ai en clientèle un fichier de plus de 700 Mo. La réindexation prend 4 minutes chez lui, mais 30 chez moi : toute la différence vient du hard (serveur "bête de course" chez le client contre vieux Pc qui n'est plus bon pour le développement mais que j'utilise pour tester sous W2000 serveur)
Bonne chance,
Victor
Salut,
"patrice" <p.labracherie_nospam_@free.fr> a écrit dans le message de news:
45688780$0$17497$426a74cc@news.free.fr...
j'ai déjà essayé de faire un hlit/recherche pour remplir un tableau des
numéros d'enregistrements (ca se fait en 2/3 secondes)
puis de supprimer tout les enregistrements, et la, ca rame grave à
nouveau.
La, je pense qu'il y a un autre problème. Il ne peut pas y avoir une telle
différence 2/3 secondes pour obtenir tous les enregs par LitRecherche et 35
Minutes pour les supprimer.
- Pas de Trigger après H.supprime ?
D'autre part, d'après ce que tu dis, j'en déduis que tu peux accéder aux
enregistrements à supprimer par un index. Donc, est-ce que cet index est
utilisé pour la suppression (filtre avec bornes Mini-Maxi)
je pense que ca vient des indexs. cela pourrait être normal, mais le cpu
reste désesperemment au repos.
Par contre, le disque s'affole ? (voyant allumé en permanence). Si oui,
c'est que tu fais des lectures. Ce serait bon d'avoir le bout de code
concerné.
je vais voir s'il est possible de supprimer sans les indexs, mais c'est ma
solution de dernier recours car la réindexaton de ce fichier nécessite
40minutes :( (700Mo data, 1.3 go de ndx)
Ca, c'est un signe : Plus que la taille du Ndx, c'est le NOMBRE d'index. Tu
dois avoir beaucoup de clés pour chaque enregistrement.
Enfin : J'ai en clientèle un fichier de plus de 700 Mo. La réindexation
prend 4 minutes chez lui, mais 30 chez moi : toute la différence vient du
hard (serveur "bête de course" chez le client contre vieux Pc qui n'est plus
bon pour le développement mais que j'utilise pour tester sous W2000 serveur)
"patrice" a écrit dans le message de news: 45688780$0$17497$
j'ai déjà essayé de faire un hlit/recherche pour remplir un tableau des numéros d'enregistrements (ca se fait en 2/3 secondes) puis de supprimer tout les enregistrements, et la, ca rame grave à nouveau.
La, je pense qu'il y a un autre problème. Il ne peut pas y avoir une telle différence 2/3 secondes pour obtenir tous les enregs par LitRecherche et 35 Minutes pour les supprimer. - Pas de Trigger après H.supprime ?
D'autre part, d'après ce que tu dis, j'en déduis que tu peux accéder aux enregistrements à supprimer par un index. Donc, est-ce que cet index est utilisé pour la suppression (filtre avec bornes Mini-Maxi)
je pense que ca vient des indexs. cela pourrait être normal, mais le cpu reste désesperemment au repos.
Par contre, le disque s'affole ? (voyant allumé en permanence). Si oui, c'est que tu fais des lectures. Ce serait bon d'avoir le bout de code concerné.
je vais voir s'il est possible de supprimer sans les indexs, mais c'est ma solution de dernier recours car la réindexaton de ce fichier nécessite 40minutes :( (700Mo data, 1.3 go de ndx)
Ca, c'est un signe : Plus que la taille du Ndx, c'est le NOMBRE d'index. Tu dois avoir beaucoup de clés pour chaque enregistrement.
Enfin : J'ai en clientèle un fichier de plus de 700 Mo. La réindexation prend 4 minutes chez lui, mais 30 chez moi : toute la différence vient du hard (serveur "bête de course" chez le client contre vieux Pc qui n'est plus bon pour le développement mais que j'utilise pour tester sous W2000 serveur)
