Bonjour,

Le question est simple.
J'ai de nombreux traitements basés sur des tables mémoires : table mémoire + fiches de saisies dans la même fenêtre, l'écriture dans les fichiers se fait en fermeture de fenêtre.

Le problème tiens dans l'alimentation de la table mémoire.

Exemple : champs sélections + requete SQL => table = 20 Sec pour 6000 lignes ( )

première idée : table mémoire=>fichier hf dynamique : 12 Sec
Seconde idée : simplification SQL
- Ote une relation dans la requete et la crée en dynamique dans la table (propriétés de colonnes) : 9 Sec

Ok : Comment faire du rapide ? parce que ces temps avec 6000 lignes font vraiment peur.

Bonnes fêtes à tous

Salut R&B,

Quel type de base de données ? Je pense HF.

As-tu essayé les vues ? les Filtres ?
si tu es en WD7, as-tu essayé les requetes après optimisation ?

Les temps que tu donnes sont en local ou en réseau (car en réso les temps HF sont démultipliés )

Salut Manu,
Effectivement les infos sont trop floues pour une réponse précise (xcuses).
Base : HF (silc)
Temps : en local (devront évoluer en VPN ou TServer)!
Le passage SQL-> hxxx est un réel mieux et montre les limites de SQL sur HF. On tente donc d'oublier SQL.

Ma question reste vonlontairement générale car je souhaite trouver une 'rêgle' pour utiliser hf dans des tables.

Pour l'instant, rien ne vaut la table fichier. mais il vaut mieux y oublier les saisies.
Notre principale utilisation est la table avec critères de sélection (filtre)
le + rapide est la table fichier donc pour les trucs tarabiscotés (plusieures lignes pour un enr) : fichier dynamique et swap de la source de la table (encore à l'étude/test)

Ainsi si pas de critères : table->fichier en direct, si critères : table->fichier dyn

Le pb est que bcp de nos fenêtre ont initialement (et naivement) été construites sur des tables memoire avec alimentation ligne à ligne : A PROSCRIRE

Oui les tables fichiers sont archi-rapides... Car ils trichent en ne chargean que ce qui est affiché dans la table:) Donc 20 ou 30 records en tout...

Il faudrait faire comme sous DOS à une époque, afficher la page en cours et "précharger" la page précédente et suivante, la première et la denière pour faire un peu de "préemptif"...

Le problème aussi de la table m"moire c'est justement la mémoire qu'elle bouffe et le temps processeur qui va avec...

Depuis la création de ce thread et grace à ton aide lmame sur le forum de DDaussy... j'ai effectivement trouvé une solution : fichier temporaires + swap Alias + table fichier.

J'expliquerais cela quand et si je pourrais mais pour informations

Chargement d'une table (5500 lignes avec bcp de solonnes)
Initial : table mémoire avec multitude accès disques + tableajouteligne : >15Mn !!!

Après ma 'bidouile' : fichier temps/alias + table fichier = 4 s (acceptable)

Les 4s restantes sont le temps de remplir le fichier temp donc difficilement compressibles.

Conclusion
- Maîtriser la description dynamique de fichiers temporaires (en fonction des autres fichiers) et utiliser les sources de données en remplacement des EXTERNE.

Ainsi comme j'ai pu le montrer pour accélerer l'import de fichier texte:
Ajouter une étape peut être plus rapide que tenter de passer en direct !

Donc remplir un temporaire et baser la table sur ce temporaire et 10x+ rapide que remplir une table mémoire.

Voila.

Pour les détails du mécanisme temps+swap il faudra attendre un peu...