WD9 - base HF Classic - requètes

I.G.LOG a formulé la demande :

WD9 - base HF Classic - requètes


Bonjour à tous,

Je cherche depuis plusieurs années (!) à trouver une solution aux lenteurs
hyperfile (pour la petite histoire, une appli en WD5.5 avec vues et ordres
h* donnait de très bon résultats en terme de performances; passée en 7.5,
puis 8 et aujourd'hui 9, les performances se sont écroulées... parfois
jusqu'à 70 fois plus lente)
Je cherche à améliorer ce code, qui ne fait que de lire une table (à partir
d'une requete) et transfere les 30 premières lignes dans une table mémoire.

Voici le code (ultra-simple):

lCond = "select REFDOC,IDDOCUMLG,DESIGNATION,'',0,0 from DOCUMLG where
IDDOCUM = 3892 order by IDDOCUMLG"
si sqlexec(lCond,"ReqI") alors
sqltable(30,"ReqI","TABLE")
fin
sqlferme("ReqI")

La table (donc les trente 1eres lignes) s'affiche, EN LOCAL, en plus de 12
secondes (assez "insupportable" pour les utilisateurs) !!!
Pourtant toutes les clés sont bien positionnées (IDDOCUM, IDDOCUMLG
primaire) et donc impossible, à mon avis, d'optimiser la requète (j'ai aussi
essayé en rendant la table invisible et divers autres astuces sans succès).
Le fichier (la table) comporte aujourd'hui 361000 tuples de longueur 299
octets et grossit en permanence (encore des inquiétudes !).


D'où mes questions:

Pensez vous qu'en HF C/S, ce sera mieux (notammment en réseau
multi-utilisateurs - rappel: essai fait en local) et de quel ordre ?
Dois je migrer en WD 10 (meilleures performances du moteur HF classic ?)
Faut-il vraiment que je migre la base vers MySQL par ex ?

merci pour vos avis

As-tu fais une réindexation ?

Si t'utilises que HyperFile pour faire des requêtes SQL, utilises alors
les fonctions HExecuteRequeteSQL() et Hxxxxxxxx à la place des fonction
SQLxxxxxxxxxx() qui sont (d'après la doc) plus rapide sur HyperFile.

Cordialement

--
Gilles TOURREAU
Responsable informatique
gilles.tourreau@pos.fr

Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr

Bonjour et merci pour la réponse.
J'ai déjà essayé avec HExecuteRequeteSQL(), sans que la différence soit
notable. pour ce qui est des ordres H*, je les ai supprimés petit-à-petit
espérant retrouver les performances de l'appli 5.5 (ce qui explique le temps
que j'ai déjà consacré aux modifs)
Toujours dans l'impasse, d'où mes question sur une évenatuelle migration en
C/S et/ou WD10 ou encore une base comme MySQL

"Gilles TOURREAU" <gilles.tourreau@pos.fr> a écrit dans le message de
news:mn.b4167d68adec1967.52180@pos.fr...

I.G.LOG a formulé la demande :
> WD9 - base HF Classic - requètes
>
>
> Bonjour à tous,
>
> Je cherche depuis plusieurs années (!) à trouver une solution aux

lenteurs

> hyperfile (pour la petite histoire, une appli en WD5.5 avec vues et

ordres

> h* donnait de très bon résultats en terme de performances; passée en

7.5,

> puis 8 et aujourd'hui 9, les performances se sont écroulées... parfois
> jusqu'à 70 fois plus lente)
> Je cherche à améliorer ce code, qui ne fait que de lire une table (à

partir

> d'une requete) et transfere les 30 premières lignes dans une table

mémoire.

>
> Voici le code (ultra-simple):
>
> lCond = "select REFDOC,IDDOCUMLG,DESIGNATION,'',0,0 from DOCUMLG where
> IDDOCUM = 3892 order by IDDOCUMLG"
> si sqlexec(lCond,"ReqI") alors
> sqltable(30,"ReqI","TABLE")
> fin
> sqlferme("ReqI")
>
> La table (donc les trente 1eres lignes) s'affiche, EN LOCAL, en plus de

12

> secondes (assez "insupportable" pour les utilisateurs) !!!
> Pourtant toutes les clés sont bien positionnées (IDDOCUM, IDDOCUMLG
> primaire) et donc impossible, à mon avis, d'optimiser la requète (j'ai

aussi

> essayé en rendant la table invisible et divers autres astuces sans

succès).

> Le fichier (la table) comporte aujourd'hui 361000 tuples de longueur 299
> octets et grossit en permanence (encore des inquiétudes !).
>
>
> D'où mes questions:
>
> Pensez vous qu'en HF C/S, ce sera mieux (notammment en réseau
> multi-utilisateurs - rappel: essai fait en local) et de quel ordre ?
> Dois je migrer en WD 10 (meilleures performances du moteur HF classic ?)
> Faut-il vraiment que je migre la base vers MySQL par ex ?
>
> merci pour vos avis

As-tu fais une réindexation ?

Si t'utilises que HyperFile pour faire des requêtes SQL, utilises alors
les fonctions HExecuteRequeteSQL() et Hxxxxxxxx à la place des fonction
SQLxxxxxxxxxx() qui sont (d'après la doc) plus rapide sur HyperFile.

Cordialement

--
Gilles TOURREAU
Responsable informatique
gilles.tourreau@pos.fr

Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr

I.G.LOG a utilisé son clavier pour écrire :

Bonjour et merci pour la réponse.
J'ai déjà essayé avec HExecuteRequeteSQL(), sans que la différence soit
notable. pour ce qui est des ordres H*, je les ai supprimés petit-à-petit
espérant retrouver les performances de l'appli 5.5 (ce qui explique le temps
que j'ai déjà consacré aux modifs)
Toujours dans l'impasse, d'où mes question sur une évenatuelle migration en
C/S et/ou WD10 ou encore une base comme MySQL

"Gilles TOURREAU" <gilles.tourreau@pos.fr> a écrit dans le message de
news:mn.b4167d68adec1967.52180@pos.fr...

I.G.LOG a formulé la demande :

WD9 - base HF Classic - requètes


Bonjour à tous,

Je cherche depuis plusieurs années (!) à trouver une solution aux lenteurs
hyperfile (pour la petite histoire, une appli en WD5.5 avec vues et ordres
h* donnait de très bon résultats en terme de performances; passée en 7.5,
puis 8 et aujourd'hui 9, les performances se sont écroulées... parfois
jusqu'à 70 fois plus lente)
Je cherche à améliorer ce code, qui ne fait que de lire une table (à partir
d'une requete) et transfere les 30 premières lignes dans une table mémoire.

Voici le code (ultra-simple):

lCond = "select REFDOC,IDDOCUMLG,DESIGNATION,'',0,0 from DOCUMLG where
IDDOCUM = 3892 order by IDDOCUMLG"
si sqlexec(lCond,"ReqI") alors
sqltable(30,"ReqI","TABLE")
fin
sqlferme("ReqI")

La table (donc les trente 1eres lignes) s'affiche, EN LOCAL, en plus de 12
secondes (assez "insupportable" pour les utilisateurs) !!!
Pourtant toutes les clés sont bien positionnées (IDDOCUM, IDDOCUMLG
primaire) et donc impossible, à mon avis, d'optimiser la requète (j'ai
aussi essayé en rendant la table invisible et divers autres astuces sans
succès). Le fichier (la table) comporte aujourd'hui 361000 tuples de
longueur 299 octets et grossit en permanence (encore des inquiétudes !).


D'où mes questions:

Pensez vous qu'en HF C/S, ce sera mieux (notammment en réseau
multi-utilisateurs - rappel: essai fait en local) et de quel ordre ?
Dois je migrer en WD 10 (meilleures performances du moteur HF classic ?)
Faut-il vraiment que je migre la base vers MySQL par ex ?

merci pour vos avis

As-tu fais une réindexation ?

Si t'utilises que HyperFile pour faire des requêtes SQL, utilises alors
les fonctions HExecuteRequeteSQL() et Hxxxxxxxx à la place des fonction
SQLxxxxxxxxxx() qui sont (d'après la doc) plus rapide sur HyperFile.

Cordialement

--
Gilles TOURREAU
Responsable informatique
gilles.tourreau@pos.fr

Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr

Utilises-tu les fichiers au format HyperFile 7 (sans les espaces) ?

Pour info, j'ai des applications Windev ou j'ai un fichier en HF
Classic de + de 200 000 enregistrements de + de 500 octets et je fais
des requêtes SQL et le résultats est instantanés...

Si maintenant tu veux faire une application en réseau traitant une
grosse base de données, je te conseille de passer dans un SGBD
client/serveur...
Je peux juste te dire qu'au niveau performance, SQL Serveur est plus
rapide que HF Classic... Pour mySQL et HF C/S, le peux pas t'en dire
plus !


Cordialement

--
Gilles TOURREAU
Responsable informatique
gilles.tourreau@pos.fr

Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr

Après vérif, les fichiers sont en mode compatible 5.5 (l'appli a été migrée
de cette version). En passant sans les espaces, ce serait plus rapide ?
Pourtant, dans la requete en exemple, les clés sont des entiers ?!

I.G.LOG avait prétendu :

Après vérif, les fichiers sont en mode compatible 5.5 (l'appli a été migrée
de cette version). En passant sans les espaces, ce serait plus rapide ?
Pourtant, dans la requete en exemple, les clés sont des entiers ?!

Ah oui ! La structure des indexes et des fichiers changent pour être
plus rapide... (Surtout au niveau de la lecture des enregistrements car
suppression des espaces)

Le mode 5.5 est juste là au cas où tu veux développer des applis qui
sont à la fois en 5.5 et 7.5 !

Tu devrais essayer... Cela ne coute rien !

Et n'oublies pas de faires les sauvegardes nécessaires afin de ne pas
me maudire après...

Cordialement

--
Gilles TOURREAU
Responsable informatique
gilles.tourreau@pos.fr

Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr

Ok, je vais essayer ça.
Encore merci, je te tiens au courrant du résultat

J'ai passé tous le fichiers en mode classic (champs terminés par /0). sur la
requete que je donne en exemple, je passe de 12 sec à 10. malheureusement
toujours pas "admissible" pour les utilisateurs. Mes questions sont donc
toujours d'actualité: C/S, WD10, MySQL
Encore merci pour vos avis (merci à Gilles notamment)

Bonsoir

SQL sur HF n'est pas la meilleur solution
en fait on ne sait pas comment pcsoft fait pour executer les requetes.
par contre nous avons des fichiers HF5.5 de 1 Go et nous n'avons pas de
problemes mais il est vrai que les index sont aussi volumineux que le
fichier. et la ou commence les problemes c'est a la reindexation pour un
fichier de ce calibre il faut 2 heures pour le reindexer donc la nuit pas
trop de soucis mais si jamais il faut le faire en journée c'est la cata.

donc pour les nouveaux dev nous avons choisi WD7.5 et mysql
j'ai des stats sur 5 ans qui font des jointures sur 5 tables dont une
contient 200 Millions d'enreg : les stat remontent en 3 secondes !

je pense que votre traitement serait plus rapide en HF qu' en SQL. car HF
reste tres rapide mais avec les ordre H. maintenant en SQL sur HF la les
performances vont tomber naturellement.

par contre attention, nous n'utilisons pas mySQL avec les ordres H nous
faisons tout en requete pure (et SQLManagerX) le resultat est assez probant
nos sites sont distant (beziers, paris nantes, avignon et nous nous
connectons sur les sites distant sans probleme et on a l'impression d'avoir
la base en locale.

bref tout est question de volume, de sites distant ou non, d'ouverture, de
modification d'analyse sans refournir un exe etc... voici en fait quelque
uns des avantages qui nous ont fait choisir la solution (acces later natif,
et SQLManagerX) je ne fais ici aucune pub, mais en 4 ans de dev sur le
projet qui doit gerer tous les entrepots en gestion commerciale, et gestion
de stock et des magasin, pour l'instant nous n'avons jamais eu de probleme
de lenteur. (plutot des problemes de stockage, la base centralisée contient
des tables a plus de 300 Millions de lignes) et certain traitement font des
jointure sur une dizaines de tables et la base commence a etre tellement
grosse qu'on rajoute des disques presque tous les 6 mois.

voila, nous avions tout essayer, HF, SQL sur HF, mysql enfin a peu pres tout



"I.G.LOG" <iglog@free.fr> a écrit dans le message de news:
44eb384b$0$874$ba4acef3@news.orange.fr...

J'ai passé tous le fichiers en mode classic (champs terminés par /0). sur
la
requete que je donne en exemple, je passe de 12 sec à 10. malheureusement
toujours pas "admissible" pour les utilisateurs. Mes questions sont donc
toujours d'actualité: C/S, WD10, MySQL
Encore merci pour vos avis (merci à Gilles notamment)

I.G.LOG avait soumis l'idée :

J'ai passé tous le fichiers en mode classic (champs terminés par /0). sur la
requete que je donne en exemple, je passe de 12 sec à 10. malheureusement
toujours pas "admissible" pour les utilisateurs. Mes questions sont donc
toujours d'actualité: C/S, WD10, MySQL
Encore merci pour vos avis (merci à Gilles notamment)

Je vous conseille de migrer à titre d'essai vos données sous HF C/S. En
utilisant uniquement des requêtes et des ordres H... sur ces requêtes,
les résulats sont tout à fait satisfaisants.

Pour ma part, j'au un "serveur" sur un Céléron (!!!!!) 1.6 mhz avec 784
Mega de mémoire et un vieux réseau Tojen ring 16 mega.

Certe le volume n'est pas très important et le nombre de connexions
simultanées = 5 mais cela marche très bien.

Je crois donc qu'un essai serait utile et vous donnera peut-être
d'exellent résultats quitte à passer à un autre C/S après (Firebirs
avec sql manager ????)

A+

--
Dr J-M des Grottes
Gestionnaire du Registre des Néphrologues Francophones de Belgique

I.G.LOG wrote:
...

Voici le code (ultra-simple):

lCond = "select REFDOC,IDDOCUMLG,DESIGNATION,'',0,0 from DOCUMLG where
IDDOCUM = 3892 order by IDDOCUMLG"
si sqlexec(lCond,"ReqI") alors
sqltable(30,"ReqI","TABLE")
fin
sqlferme("ReqI")

La table (donc les trente 1eres lignes) s'affiche, EN LOCAL, en plus de 12
secondes (assez "insupportable" pour les utilisateurs) !!!
Pourtant toutes les clés sont bien positionnées (IDDOCUM, IDDOCUMLG
primaire) et donc impossible, à mon avis, d'optimiser la requète (j'ai aussi
essayé en rendant la table invisible et divers autres astuces sans succès).

...

Pensez vous qu'en HF C/S, ce sera mieux (notammment en réseau
multi-utilisateurs - rappel: essai fait en local) et de quel ordre ?
Dois je migrer en WD 10 (meilleures performances du moteur HF classic ?)
Faut-il vraiment que je migre la base vers MySQL par ex ?

Bonjour,

je ne suis pas enchanté par les requêtes sur HF, mais dans le cas décrit
je vois mal la raison. Ce type de requête est traité de manière
relativement rapide par HF, à l'exception de 2 cas de figure:

1) Les index: IDOCNUMLG doit être une clé individuelle. Sous "IDDOCUM,
IDDOCUMLG primaire" je comprends que c'est une clé primaire composé. Or,
cela ne marche pas bien avec HF. S'il faut aussi accéder à la clé
composé, alors il faudrait avoir trois clés: une multiple sur IDDOCNUM,
une multiple sur IDDOCNUMLG et une clé unique composé sur IDDOCNUM +
IDDOCNUMLG. La raison: la recherche est uniquement sur IDDOCNUM et le
tri sur IDDOCNUMLG. Sur n'importe quelle taille du fichier, un résultat
avec juste 30 lignes sans autres critères de sélection doit être instantané.

A part cela et juste pour info, ORDER BY est le rallentisseur N°1, à
coté de hNbEnr, surtout lorsqu'il y a beaucoup de lignes dans le résultat.


2) J'ai lu que les fichiers ont été convertis en HF Classic WD9: il faut
s'assurer que les fichiers ont été re-indexé avant de faire les tests,
sinon le résultat risque ne pas changer.


Je ne pense pas que HF C/S apporterais une différence dans ce cas. Ce
moteur est uniquement plus puissant pour les requêtes multi-fichiers (WD9).

Je ne pense non plus que WD10 apporterais une différence, car
l'amélioration que j'ai noté est sur les requêtes multi-fichiers. Ces
derniers offrent maintenant à peu près la rapidité de HF C/S (sans pour
autant arriver au niveau de produits concurrents).

Salutations
Mat