Bonjour à tous,

J'ai un problème avec un fichier comportant 1 000 000 d'enregistrements de ligne de commandes .
Lorsque je lance mon application le matin, le premier enregistrement que j'effectue dans ce fichier prend du temps pour se faire (45 secondes à 2 minute). Parfois il se plante carrément.
Après ce premier enregistrement, les autres se passent normalement, sans perte de temps.
Le problème est identique si c'est une suppression qui est effectué en premier
avec un filtre ( qui devrait supprimer une vingtaine de ligne,avec une seule cle numérique comme critère de filtre)

En fait au premier appel d'ajout ou de suppression , on dirait que l'appli charge entièrement l'index
du fichier .
Le problème se pose aussi bien en HF client/Serveur ou local.
Les index sont réduits au stricte nécessaire et optimiser, pas d'antivirus, pas de journalisation.


Est ce que quelqu'un pourrait m'aider à remédier au problème ? (Phénomène inconnu par le ST , comme d'hab.)

merci
JYM

J'ai remarqué que le HFiltre créer quelquefois des disfonctionnements au niveau des temps d'accés !!!

Essaye peut etre la même opération avec une boucle

HLitRecherchePremier(Table,Clé,Valcherchée)
TANTQUE pas HENDEHORS() _et_ HTROUVE()
...
HLitSuivant(Table,Clé)
FIN

Ou une requête SQL...

Tiens moi au courant !!

tu peux utiliser "HOptimise".
Le programme va charger les indexs du fichier en fond.

Merci pour vos reponses,
- Concernant Hoptimise le problème est déplacé lors de l'appel de cette fonction , hoptimise met 2 minutes avant
de me rendre la main , il charge entièrement l'index en mémoire i.e 300 Mo !!! et ensuite l'ajout et suppression se fait sans problème.
Donc apparemment , que ce soit le premier ajout, la première suppression ou hoptimise dans tous les cas
il charge entièrement l'index.
imaginons si le fichier d'index pèse 1 Go , il faudra presque autant de mémoire vive que la taille du disque dur...


- Pour Machou73 , le code que tu préconise est celui que j'utilise.
en Sql c'est une catastrophe , là le temps est multiplié
par 10.
Merci encore ,
Il faut que je creuse encore , car le phénomène ne fera
qu'empirer avec le temps.
je vous tiens au courant.

JYM

je présume que tu as créé une fenêtre avec une table.

Aurais-tu pas hasard un hcreationsiinexistant() à l'initialisation de cette fenêtre ?

Bonjour,

Citation :
non, le hcreationsiinexistant est effectué à l'ouverture du projet,
Concernant les tables , j'ai quasiment banni
l'utilisation des tables fichiers ,

Dans mon cas ,je suis dans une fenêtre de saisie de commande, et je n'utilise qu'une table mémoire ,alimentée par une requête (qui d'ailleurs elle est rapide.)

JYM

Bonjour,

Le HcrationSiInexistant() est fort long il est vrai, mais présente certain interêt dans des cas bien précis.

Il est préferaable par exemple de ne le laisser s'exécuter que lorsque qu'une erreur tel que fichier inexistant est rencontrée.

Citation :

Il faut savoir que dans la plupart des cas les tables fichiers sont les plus rapides de par leurs modes de fonctionnement et surtout lorsque les fichiers sont conséquants.
seuls les lignes affichées ont transitées sur le réseau.

J'ai effectués quelques tests sur un acces distant via internet et les tables fichiers ont étés les plus rapides.

D'ou l'intérêt d'etudier les conséquences de ses choix en fonction aussi du poids des fichiers et de leurs evolutions et non basé que sur des fichiers test de quelques enregistrements.

tout a fait les tables fichiers n'utilisent que le nombre d'enreg visible à l'écran alors que la table mémoire se charge en entier.
Donc dans ton cas si j'ai bien compris:

tu charges ta table mémoire (1000000 as-tu dis) puis tu execute un filtre sur le fichier pour supprimer des lignes

il me semble normal que cela aille lentement.

mais est ce que ton 1 000 000 de ligne de commande représente 1 000 000 de factures ? car dans une facture il y a généralement un entete, ce qui réduirait tes lignes.

Merci de vos réponses,
Mais jamais JE NE REMPLIRAI une table mémoire avec
1 000 000 d'enr. !!! (une pure folie)
( d'ailleurs j'ai pas mal contribuer sur ce forum , pour expliquer aux développeurs qu'il fallait toujours remonter que le stricte minimum d'enr. via hfiltre ou requête selective pour que l'appli soit performante)

Ma requête me retourne qu'une vingtaine de ligne sur les
1 000 000 d'enr.! et pour la requête de suppression idem.

Quand je dis que j'ai banni les tables fichiers ,
c'est qu'en acces distant les tables fichiers sont à proscrire.
et d'autre par effectivement en local les tables fichiers sont extremement rapide à l'affichage initial de fichiers volumineux,si et seulement si vous enlever la possibilité à l'utilisateur de pouvoir trier sur les colonnes.
sinon vous pouvez aller prendre un café.

JYM

Bonjour :

1- Concernant la création des fichiers en ouverture :
il
HCréationSiInexistant("*",houvertureDifferee)

2- 100k enregistrements n'est pas un soucis si on sort du TDF 2006 (avec la table a 10 000 k enregistrements ! et le filtre en deux secondes)... Le problème n'est donc pas vraiment là !

Maintenant j'ai une question :
comment monte tu ton filtre ?
a- sur une clé ? clé simple ou composée ? si composée : clé importée (par relation) ? et de quel type de rubrique s'agit-il ?

b- S'agit-il d'un filtre sur condition ou sur clé ? comment sont gérés les bornes

c- Comment accèdes tu à ton enregistrement ? hLITxxx ou hXXX (plus rapide car ne monte pas l'enregistrement dans le tampon).

Ne désespère pas ! A force de chercher on va trouver...

Salut Romuald ,

alors voilà :

un fichier commande (438 octets par enr.)
clé unique NumCde entier sur 8 octets

(liaison 0,n 1,1) par numCde

un fichier ligneCommande (216 octets par enr.)
dont 2 rubriques mémos peut souvent remplies
LigneCommande possède une clé étrangère unique
ligneCommande_PK : Numcde+NumLigne

(NumLigne entier sur 2 octets)


Phénomene !
Soit :
Création de la première commande :
(création donc aucun filtre) .
l'ajout de la première ligne de commande met 2 mn.
ensuite aucun souci même pour de nouvelle commande saisie.

Soit
Modification d'une première commande:
Pour des raisons pratiques , je suis obligé d'éffacer toutes les lignes d'une commandes dans la base et de les ajoutées ensuite.
le nombre de ligne par commande est d'environ 20.

Les 2 minutes d'attentes ou plantage du pc , se font
au premier appel de l'application à la fonction
hajoute ,ou hsupprime (avec le disque dur qui tourne un max)
Ensuite pas de problème

// ouverture du projet
hcreationsiinexistant("*")
--> 1 seconde

pour l'ajout de ligne de commande.
Hajoute(lignecde)


pour la suppression :
j'ai essayé 2 méthode:
REQ_SUPP_LIGNECDE.P_NUMCDE=commande.NUM_CDE
HExécuteRequête(REQ_SUPP_LIGNECDE)
ou
HFiltre(LIGNECDE,NUM_CDE,COMMANDE.NUM_CDE,COMMANDE.NUM_CDE)
HLitPremier(LIGNECDE,NUM_CDE)
TANTQUE PAS HEnDehors(LIGNECDE)
HSupprime(LIGNECDE)
HLitSuivant(LIGNECDE,NUM_CDE)
FIN
HDésactiveFiltre(LIGNECDE)
(j'ai aussi essayé en filtrant sur ligneCommande_PK)

au déboggeur , le hfiltre est immédiat c'est vraiment sur la fonction hsupprime que ce la m...

Nb : Aucun Trigger , ni de table fille sur ligneCommande.
pour tout ce qui est lecture d'enr. aucun souci.

J'ai l'impression que Windows essaye de charger en cache tout les index du fichier ligneCommande au premier appel de d'une de ces deux fonctions.

(j'ai aussi essayé hoptimise() au démarrage
du projet et là le phénomène n'apparait plus dans la saisie ou modification de commande mais à l'ouveture (logique), soit l'application rend la main au bout de 3 ,4 minnutes
ou alors plante carrément (toujours au premier lancement de la journée).

j'ai effectué les tests en client/ serveur.
et là idem, sauf que c'est le disque dur serveur qui se met à tourner pendant 2 minutes.
Tester au déboggeur,c'est vraiment la commande hajoute ou hsupprime qui déclenche le phénomène.


Peut-être une piste , a savoir qu'a chaque ligne de produit affichée dans la fiche de commande , un calcul statistique est effectué sur ligneCommande concernant le produit en cours et le client.( stat calculé par requête)
mais aucun temps d'attente concernant cet affichage, et requete annulée si tôt affichée, et retour du pointeur sur la commande en cours)


JYM

en mettant des options comme HIgnoreIntégrité pour hsupprime et hajoute y a 'il un impacte?

As tu contrôler tes fichiers index?