[WD8] HExécuteRequêteSQL() en réseau

Real Phil wrote:

Bonjour,

ReqClient est une source de données
HExécuteRequêteSQL(ReqClient,"SELECT NOM FROM CLIENT WHERE condition ")

La question est pour ceux qui travaillent en réseau.
L'aide mentionne « Si une requête de même nom est déjà déclarée, elle est
remplacée par la nouvelle requête. »
Je présume que l'aide veut dire par le même poste mais je veux en être
certain.

Alors comment Windev gère-t-il cela quand plusieurs postent appellent cette
même requête en même temps? Gère-t-il cela automatiquement ou si le
programmeur doit remplacer lui-même le nom ReqClient par un nom différent à
chaque poste?

Bonjour Réal,
Les requêtes sur HF créent le résultat uniquement en mémoire. Un
changement d'une requête n'a un effet que sur le poste concerné, qui
dépend en plus du réglage des fenêtres en ce qui concerne le contexte
Hyper File (indépendant ou pas). Avec le contexte indépendant je peux
exécuter deux requêtes différentes portant le même nom dans deux
fenêtres différents. Autrement, la définition et le résultat de la 2e
exécution remplacent ceux de la première.
Salutations
Mat

Bonjour,

Les requêtes sur HF créent le résultat uniquement en mémoire. Un
changement d'une requête n'a un effet que sur le poste concerné, qui
dépend en plus du réglage des fenêtres en ce qui concerne le contexte
Hyper File (indépendant ou pas). Avec le contexte indépendant je peux
exécuter deux requêtes différentes portant le même nom dans deux
fenêtres différents.

<Autrement, la définition et le résultat de la 2e

exécution remplacent ceux de la première.
Salutations
Mat

Même si la source de données est locale à la fenêtre ( Déclaration
en variable globale de la fenêtre ) ?

Sébastien

sebNews wrote:

Bonjour,

Les requêtes sur HF créent le résultat uniquement en mémoire. Un
changement d'une requête n'a un effet que sur le poste concerné, qui
dépend en plus du réglage des fenêtres en ce qui concerne le contexte
Hyper File (indépendant ou pas). Avec le contexte indépendant je peux
exécuter deux requêtes différentes portant le même nom dans deux
fenêtres différents.

<Autrement, la définition et le résultat de la 2e

exécution remplacent ceux de la première.
Salutations
Mat

Même si la source de données est locale à la fenêtre ( Déclaration
en variable globale de la fenêtre ) ?

Voici ce qu'on trouve à ce sujet chez wdforge.org:

Portée
Attention à la portée des sources de données Une fois déclarée et
affectée, la source de données est considérée comme faisant partie
intégrante de l'analyse.
Cette notion brouille quelque peu la notion de portée des variables
sources de données dans un projet.
En effet, une source de donnée peut être décrite dans une fenêtre... et
une autre de même nom dans une autre fenêtre.
En théorie, si l'on suit la gestion des portées des variables, rien ne
s'oppose à cela. Sauf que si les fenêtres sont ouvertes en même temps,
le moteur HyperFile® génère une erreur.
Il les interprète comme deux fichiers... de même nom avec des
descriptions qui diffèrent.

> Voici ce qu'on trouve à ce sujet chez wdforge.org:

Portée
Attention à la portée des sources de données Une fois déclarée et
affectée, la source de données est considérée comme faisant partie
intégrante de l'analyse.
Cette notion brouille quelque peu la notion de portée des variables
sources de données dans un projet.
En effet, une source de donnée peut être décrite dans une fenêtre... et
une autre de même nom dans une autre fenêtre.
En théorie, si l'on suit la gestion des portées des variables, rien ne
s'oppose à cela. Sauf que si les fenêtres sont ouvertes en même temps,
le moteur HyperFile® génère une erreur.
Il les interprète comme deux fichiers... de même nom avec des
descriptions qui diffèrent.

Précision importante

Sébastien

> Bonjour Réal,
Les requêtes sur HF créent le résultat uniquement en mémoire. Un
changement d'une requête n'a un effet que sur le poste concerné, qui
dépend en plus du réglage des fenêtres en ce qui concerne le contexte
Hyper File (indépendant ou pas). Avec le contexte indépendant je peux
exécuter deux requêtes différentes portant le même nom dans deux
fenêtres différents. Autrement, la définition et le résultat de la 2e
exécution remplacent ceux de la première.
Salutations
Mat

=========================================== Bonjour Mat,

Merci pour la réponse.
Le résultat en mémoire des requêtes simplifie bien des choses pour mes
projets.

En passant, j'ai eu à faire quelques tests de recherches parmi une base de
donnée de plus de 75000 enregistrements. Je demeure encore inquiet et
méfiant sur la vitesse - je ne maîtrise pas encore toutes les facettes de
WD8 et je me souviens de tout ce qui a été dit sur la lenteur relative de
WD. Et encore pire en réseau.

Donc, je recherchais environ 50 enregistrements dans une base de plus de
75000 enregistrements.
Mes premiers essais ont été terribles... de la mélasse... décourageant. J'ai
sûrement dû mal coder mes filtres.

Puis j'ai essayé HExécuteRequêteSQL()... wow! résultat direct et instantané,
même si mon ordinateur est relativement vieux. Mieux encore, un poste relié
encore beaucoup plus vieux avec Windows 95 a donné des résultats
pratiquement instantané aussi.

Voilà qu'il y a de l'espoir dans l'air...

Mes meilleures salutations Mat.

Réal Phil

Real Phil wrote:

Bonjour Mat,

Merci pour la réponse.
Le résultat en mémoire des requêtes simplifie bien des choses pour mes
projets.

Pas pour les miens, puisque tous les essais en comparaison avec Visual
Foxpro et Paradox qui travaillent avec exécution de la requête sur le
poste "client" ont été plusieurs fois plus rapides que HF si les
dernières n'ont pas la possibilité de se terminer en arrière plan, et
cette possibilité existe très souvent, c'est à dire qu'on prend en
considération le temps réel du début à la fin du traitement de la requête.

En passant, j'ai eu à faire quelques tests de recherches parmi une base de
donnée de plus de 75000 enregistrements. Je demeure encore inquiet et
méfiant sur la vitesse - je ne maîtrise pas encore toutes les facettes de
WD8 et je me souviens de tout ce qui a été dit sur la lenteur relative de
WD. Et encore pire en réseau.

Donc, je recherchais environ 50 enregistrements dans une base de plus de
75000 enregistrements.
Mes premiers essais ont été terribles... de la mélasse... décourageant. J'ai
sûrement dû mal coder mes filtres.

Puis j'ai essayé HExécuteRequêteSQL()... wow! résultat direct et instantané,
même si mon ordinateur est relativement vieux. Mieux encore, un poste relié
encore beaucoup plus vieux avec Windows 95 a donné des résultats
pratiquement instantané aussi.

Salut Réal,

Je suis content pour toi si les conditions de tes tests correspondent à
tes besoins... je ne peux certes pas dire autant pour moi. J'ai constaté
à plusieurs reprises que le problème n'est pas le nombre
d'enregistrements à traiter, mais le nombre dans le résultat, et si ce
résultat provient d'un seul ou de plusieurs fichiers et si HF peut
utiliser un index d'un fichier source pour lire le résultat plus
rapidement. Difficile s'il y a plusieurs fichiers sources et un trie
portant sur des rubriques de plusieurs fichiers. J'ai pris deux ans pour
comprendre qu'une requête windev sur HF n'a strictement rien à voir avec
une requête telle qu'on connaît sous Visual Foxpro ou Paradox. Le
problème est que PC Soft ne le disent pas et n'expliquent nulle part le
fonctionnement de leur version. En fin de compte, une requête HF n'est
pas très différent d'un filtre (ce qui explique le besoin d'index sur le
fichier source dans l'ordre de tri de la requête pour accéder rapidement
le résultat).

L'autre problème avec les requêtes sur HF est la modification
contemporaine des mêmes fichiers sur un autre poste. Ceci ralenti
l'exécution lorsque plusieurs fichiers source sont concernés. Puisque le
modèle de mon application principale est basé sur des requêtes, j'ai
finalement réussi à obtenir des temps d'exécution plus ou moins corrects
en réduisant toutes les requêtes source de tables à un seul fichier. Ce
n'est pas du tout l'idée de requêtes SQL, je le trouve même plutôt
pervers. En plus, afin d'obtenir des temps d'ouverture de fenêtres
acceptables, tous les combos alimentés par des requêtes ne sont chargés
qu'au moment du premier accès.

La seule situation dans laquelle une requête sur HF est plus efficace
d'un produit concurrent est le parcours du résultat, une fois qu'elle a
été exécuté complètement, puisqu'elle réside entièrement en mémoire.

Salutations
Mat

sebNews wrote:

Voici ce qu'on trouve à ce sujet chez wdforge.org:

Portée
Attention à la portée des sources de données Une fois déclarée et
affectée, la source de données est considérée comme faisant partie
intégrante de l'analyse.
Cette notion brouille quelque peu la notion de portée des variables
sources de données dans un projet.
En effet, une source de donnée peut être décrite dans une fenêtre... et
une autre de même nom dans une autre fenêtre.
En théorie, si l'on suit la gestion des portées des variables, rien ne
s'oppose à cela. Sauf que si les fenêtres sont ouvertes en même temps,
le moteur HyperFile® génère une erreur.
Il les interprète comme deux fichiers... de même nom avec des
descriptions qui diffèrent.

Précision importante

mais malheureusement pas clair non plus. Puisque je n'ai jamais eu de
problèmes, je voulais savoir si j'ai juste eu de la chance parce que
j'utilise les sources de données souvent dans des circonstances
particulières. Alors j'ai fait un test avec deux fenêtres, une avec une
table pour les produits et l'autre pour les clients.

- Les deux fenêtres sont ouvert par un bouton sur le menu principal
avec OuvreFille.
- La table s'alimente par une requête SQL "SELECT * FROM ... " et
FichierVersTableMémoire, par le clic sur un bouton

Déclarations globales de la fenêtre:
// version avec source de donné locale
vSQL est une Source de Données
HExécuteRequêteSQL(vSQL, "SELECT * FROM NomFichier")


Bouton TableRefresh:
FichierVersTableMemoire(Table1, vSQL)

A) On ouvre Fenêtre1, remplit la table Produit et laisse ouvert la fenêtre
B) On ouvre Fenêtre2, rempli la table Adresse et laisse ouvert la fenêtre
C) On rafraîchit la table de Fenêtre1


1) Le résultat est que le comportement est le même pour une source de
donnée locale à une fenêtre qu'une source de donnée globale au projet.

2) Si les fenêtres n'ont pas de contexte HF indépendant, la définition
de la requête est simplement remplacé par une 2e exécution avec les
données de l'autre fenêtre. Aucune erreur n'est généré dans le cas
décrit. Dans le test, après C) la table de Fenêtre1 montre maintenant
les clients.

3) Le contexte HF indépendant garanti que les données ne changent pas
pour des requêtes utilisant des sources de données du même nom. Dans le
test, après C) la table de Fenêtre1 donne toujours les produits.

En fin de compte, la même chose que pour les requêtes ordinaires.

Salutations
Mat

Re-bonjour Mat,

Real Phil wrote:
> Bonjour Mat,
>
> Merci pour la réponse.
> Le résultat en mémoire des requêtes simplifie bien des choses pour mes
> projets.

Pas pour les miens, puisque tous les essais en comparaison avec Visual
Foxpro et Paradox qui travaillent avec exécution de la requête sur le
poste "client" ont été plusieurs fois plus rapides que HF si les
dernières n'ont pas la possibilité de se terminer en arrière plan, et
cette possibilité existe très souvent, c'est à dire qu'on prend en
considération le temps réel du début à la fin du traitement de la requête.

Là-dessus, aucun doute que Foxpro (je ne connais pas Paradox) est de loin
plus rapide en exécution de la grande majorité des combinaisons de codes
SQL. Pas trop besoin de faire des entourloupettes à chercher la meilleure
solution pour obtenir une vitesse optimale dans la plupart des cas comme en
Windev.

>
> En passant, j'ai eu à faire quelques tests de recherches parmi une base

de

> donnée de plus de 75000 enregistrements. Je demeure encore inquiet et
> méfiant sur la vitesse - je ne maîtrise pas encore toutes les facettes

de

> WD8 et je me souviens de tout ce qui a été dit sur la lenteur relative

de

> WD. Et encore pire en réseau.
>
> Donc, je recherchais environ 50 enregistrements dans une base de plus de
> 75000 enregistrements.
> Mes premiers essais ont été terribles... de la mélasse... décourageant.

J'ai

> sûrement dû mal coder mes filtres.
>
> Puis j'ai essayé HExécuteRequêteSQL()... wow! résultat direct et

instantané,

> même si mon ordinateur est relativement vieux. Mieux encore, un poste

relié

> encore beaucoup plus vieux avec Windows 95 a donné des résultats
> pratiquement instantané aussi.

Salut Réal,

Je suis content pour toi si les conditions de tes tests correspondent à
tes besoins...

Je suis loin d'avoir tout essayé comme situation. Tu as une bonne longueur
d'avance sur moi dans ce sens.
Mais pour l'instant je m'attendais à tellement pire avec tout ce que j'ai lu
à ce sujet que j'était content de ces résultats.

...je ne peux certes pas dire autant pour moi. J'ai constaté
à plusieurs reprises que le problème n'est pas le nombre
d'enregistrements à traiter, mais le nombre dans le résultat,

...je dois avouer que je m'en attendais un peu mais je suis content
d'apprendre cette précision.

et si ce résultat provient d'un seul ou de plusieurs fichiers et si HF

peut

utiliser un index d'un fichier source pour lire le résultat plus
rapidement. Difficile s'il y a plusieurs fichiers sources et un trie
portant sur des rubriques de plusieurs fichiers. J'ai pris deux ans pour
comprendre qu'une requête windev sur HF n'a strictement rien à voir avec
une requête telle qu'on connaît sous Visual Foxpro ou Paradox. Le
problème est que PC Soft ne le disent pas et n'expliquent nulle part le
fonctionnement de leur version. En fin de compte, une requête HF n'est
pas très différent d'un filtre (ce qui explique le besoin d'index sur le
fichier source dans l'ordre de tri de la requête pour accéder rapidement
le résultat).

Mais Foxpro aussi sera considérablement plus rapide si sa requête SQL est
basée sur un index.

L'autre problème avec les requêtes sur HF est la modification
contemporaine des mêmes fichiers sur un autre poste. Ceci ralenti
l'exécution lorsque plusieurs fichiers source sont concernés. Puisque le
modèle de mon application principale est basé sur des requêtes, j'ai
finalement réussi à obtenir des temps d'exécution plus ou moins corrects
en réduisant toutes les requêtes source de tables à un seul fichier. Ce
n'est pas du tout l'idée de requêtes SQL, je le trouve même plutôt
pervers. En plus, afin d'obtenir des temps d'ouverture de fenêtres
acceptables, tous les combos alimentés par des requêtes ne sont chargés
qu'au moment du premier accès.

La seule situation dans laquelle une requête sur HF est plus efficace
d'un produit concurrent est le parcours du résultat, une fois qu'elle a
été exécuté complètement, puisqu'elle réside entièrement en mémoire.

En effet, on ne peut plus rapide.

Salutations
Mat

J'apprécie toutes ces informations parce que cela me donne des indications
plus nettes envers les opérations dont je dois me méfier. Mais je dois
avouer que même en Foxpro, tout n'a pas été avec des résultats fulgurants
nécessairement du premier coup. Je ne parle pas des petites requêtes SQL
simples bien sûr.

Je ne sais pas pour toi, mais il m'est arrivé souvent pour des projets assez
importants en Foxpro (du style 35 usagers ou plus en réseau) avec beaucoup
de volume, de chercher des solutions à vitesses optimales. Même si c'est
habituellement très rapide comme résultats on veut souvent encore plus vite.
Et je dois avouer que je ne faisais pas toujours une confiance aveugle au
SQL de Foxpro au point de vue vitesse optimale. Alors il m'est arrivé assez
souvent de décortiquer une opération SQL en plusieurs étapes et d'en obtenir
des augmentations de vitesse considérable. J'espère que je saurai être aussi
inventif avec Windev et en obtenir des résultats relativement acceptables.

Salutations Mat,

Réal Phil

Real Phil wrote:
...

Mais Foxpro aussi sera considérablement plus rapide si sa requête SQL est
basée sur un index.

...
Oui, pour la sélection, mais chez Windev/HF c'est aussi pour la
présentation (le tri et l'accès) du résultat.

Je ne sais pas pour toi, mais il m'est arrivé souvent pour des projets assez
importants en Foxpro (du style 35 usagers ou plus en réseau) avec beaucoup
de volume, de chercher des solutions à vitesses optimales. Même si c'est
habituellement très rapide comme résultats on veut souvent encore plus vite.
Et je dois avouer que je ne faisais pas toujours une confiance aveugle au
SQL de Foxpro au point de vue vitesse optimale. Alors il m'est arrivé assez
souvent de décortiquer une opération SQL en plusieurs étapes et d'en obtenir
des augmentations de vitesse considérable.

...
je crois c'est pareil pour tout BD en file share sauf Hyper File. En
partie c'était probablement due aux limitations de mémoire vive,
vitesses réseaux et disques. Par contre, enchaîner des requêtes HF
ralenti le tout considérablement, même la compilation du projet devient
notablement plus longue.

Je pense que la raison se trouve dans le fait qu'avec des requêtes
classiques, comme Foxpro ou Paradox, on traite des fichiers sur disque,
ce qui devient toujours plus efficace avec chaque requête éliminant des
enregistrements, tandis que dans HF chaque nouvelle requête ajoutée
semble compliquer davantage la sélection et relation des données.

De toute façon il serait intéressant de savoir si quelqu'un à déjà
obtenu une amélioration des temps d'exécution avec des requêtes
enchainées. Je n'ai jamais vu une affirmation de ce genre.

Salutations
Mat

>
3) Le contexte HF indépendant garanti que les données ne changent pas
pour des requêtes utilisant des sources de données du même nom. Dans le
test, après C) la table de Fenêtre1 donne toujours les produits.

En fin de compte, la même chose que pour les requêtes ordinaires.

Je n'utilise pas le contexte HF indépendant ( je ne sais pas se cache
derrière
mais j'imagine ; des Hsauveposition et Hretourposition ( voir version 5.5B)

Cela veut dire que en arrière plan, les contexte sont rétablis dans tes
fichiers.
Et si ta source de données inclus plusieurs fichiers avec jointures cela
peut provoquer un ralentissement non ?

Je pense qu si tu as vraiment besoin de faire des requêtes avec beaucoup de
volume
en data et en résultats : il faut passer sur un modèle Client Serveur.

Par contre HF C/S ( pas encore testé à fond) semble être un serveur de
communication
entre les données HF Fichiers et l'appli cliente Non?
Difficile de comparer avec un produit SGBD C/S du type Mysql ou SqlServeur

Sébastien