Requête sur vue

Omega a formulé la demande :

Bonjour,

Est il possible de faire une requête sur une vue ?

Merci d'avance ...

La fonction HexecuterequeteSQL peut travailler sur une variable source
de données, donc c?est sans doute possible. Par contre je ne suis pas
certain que le mélange des deux techniques soit bon.
Pour tirer pleinement profit des vues, je te conseille de faire une
restriction sur le fichier avant de créer la vue, en positionnant un
filtre (Hfiltre).
Mais de plus en plus je laisse les vues de côté en privilégiant les
requêtes (avec des statistiques d'index régulièrement mises à jour).

--
forumnewswindev@ifrance.com

JBT avait écrit le 07/07/2004 :

Omega a formulé la demande :

Bonjour,

Est il possible de faire une requête sur une vue ?

Merci d'avance ...

La fonction HexecuterequeteSQL peut travailler sur une variable source de
données, donc c?est sans doute possible. Par contre je ne suis pas certain
que le mélange des deux techniques soit bon.
Pour tirer pleinement profit des vues, je te conseille de faire une
restriction sur le fichier avant de créer la vue, en positionnant un filtre
(Hfiltre).
Mais de plus en plus je laisse les vues de côté en privilégiant les requêtes
(avec des statistiques d'index régulièrement mises à jour).

Précision en ce qui concerne les statistiques d'index et les requêtes.
J'ai fait des essais après la publication de la faq suivante par pcsoft :
http://faq.pcsoft.fr/webdev7/faqread.awp?idfaq(66

J'ai des requêtes dont le temps de traitement a été divisé à 5 !!!

--
forumnewswindev@ifrance.com

JBT wrote:

Précision en ce qui concerne les statistiques d'index et les
requêtes. J'ai fait des essais après la publication de la faq
suivante par pcsoft :
http://faq.pcsoft.fr/webdev7/faqread.awp?idfaq(66

J'ai des requêtes dont le temps de traitement a été divisé à 5 !!!

Après avoir foutu en air encore quelques heures à cause de Windev / HF
pour des raisons totalement idiot (une chose que j'aurais pu faire en
quelques minutes avec un autre produit) je me suis quand-même décide à
observer qu'il vaudrait mieux revoir à priori ce système de fichiers
totalement démodé.

En principe d'accord qu'il faudrait commencer à abandonner les vues en
faveur de requêtes. Mais il y a toujours des gens qui disent que les
vues sont plus rapides pour eux.

Personellement, j'ai trouvé que dans le cas de tris, les recommendations
des index n'ont un effet important que lorsqu'il s'agit d'un seul
fichier. Dans la vie réelle on a pour la plupart des cas à faire avec
des requêtes sur plusieurs fichiers et des tris sur plusieures rubriques
originaires de plusieurs fichiers. En WD 7.5 les optimisations n'ont pas
aidé à accélerer ces cas et pour autant que j'ai lu, la même chose est
vrai pour la version 8. Dans des comparaisons effectuées l'année passée
sur des fichiers identiques, nous avons pu constater que Paradox, Foxpro
et Delphi ne montrent aucun ralentissement notable lorsqu'on trie dans
une requête. Ces produits concurrents testés ne sont notablement pas de
la dernière génération comme se dit Windev. Paradox7 a bientôt 10 ans et
aussi les versions de Foxpro et Delphi étaient des versions anciennes.

Alors, ne serait-il pas mieux d'améliorer Windev/HF au lieu de continuer
à proposer des béquilles? Autres observations:

- Les requêtes SQL exécutés avec HExecuteRequêteSQL ne se comportent pas
toujours comme prévu. J'ai toujours trouvé des optimisations ou
contournements, mais des fois seulement après des heures, voir jours, de
recherche. Je n'aime pas trop ACCESS, mais j'ai fait des requêtes
similaires avec et n'ai jamais connu ces problèmes. Développer 10 fois
plus rapide: dans vos rêves, peut-être.

- Windev/HF impose qu'une rubrique de liaison soit une clé des deux
cotés de la liaison, ce qui gonfle les index et rallenti surement la
gestion de ceux-ci. Pourquoi l'ID d'une condition de livraison dans un
fichier client devrait être une clé? Dans le 99% des cas on ne va pas
parcourrir le fichier dans cette ordre. Pourtant, s'il ne l'est pas,
aucune possibilité de lier les conditions de livraison au client.

- Le résultat du besoin accru d'index de Windev/HF est le suivant:

FIC/DB = taille fichier en KB, NDX = taille fichier index, Paradox total des fichiers index (primaire et secondaires)., Nb. = nombre
d'index sur le fichier.

Windev/HF 7.5 Paradox 4 / 7 (1992-1996)
Fichier Enr. FIC NDX Nb. Enr. DB NDX Nb.
Clients 977 732 538 18 876 723 36 2
Commandes 2530 1526 1267 22 2615 2147 12 1
LignesComm. 4041 1649 1928 21 4290 1467 205 3
Mouvements 20994 5416 10277 19 21919 2467 39 1

Les fichiers ne sont pas totalement identiques et la taille des fichiers
de données n'est pas en cause. Que Windev/HF nécessite autant d'index et
que les fichiers index aient une taille tellement importante, OK
l'espace disque n'est plus un problème aujourd'hui dans la plupart des
cas. Mais ça n'aide surement pas l'efficacité en réseau.

- Une clé de liaision doit être soit un entier, soit il faut créer, et
manuellement gérer, une rubrique binaire dans le fichier relié dans le
cas d'index composés. Une autre solution est d'avoir un ID automatique
dans le fichier. Ceci ne me plait pas dans le cas de fichiers importants
avec clés composés, comme les lignes de commandes, factures, etc.
D'autres produits n'imposent pas ces limites.

- D'autres bases de données sont plus intélligentes que Windev/HF.
Depuis plus d'une dizaine d'années déja Paradox crée automatiquement un
index secondaire sur une rubrique lorsqu'il calcule qu'une recherche ou
une requête serait alors exécuté plus rapidement. Une exellente solution
pour des cas isolés et certes mieux que faire attendre l'utilisateur
pendant plusieures minutes.

- HF ne permet pas de changer le mot de passe de fichiers par
programmation. Une fois installé en clientèle, on ne peut plus le
changer. Pour moi, ceci réduit fortement la valeur de la protection.
D'autres bases offrent plus de flexibilité avec un simple
PROTECT "NomFichier" "MotDePasse".

- Pourquoi l'analyse avec sa rigidité. Je travaille depuis plus de 20
ans avec des bases de données de toute sorte et je n'ai jamais perdu
autant de temps afin de travailler réellement avec des données sous
forme de fichier. Non seulement, et contrairement au standard, Windev
était pour ainsi dire inutilisablement lent sous OCDB (et l'est
peut-être toujours). Windev est si bête à ne même pas reconnaitre ses
propres fichiers! Avec n'importe quelle autre base de données intégrée
que je connais, je peux simplement passer les enregistrements d'un
fichier à un autre. Si j'ai un fichier, je l'ouvre tout simplement et je
l'oublie, lorsque je n'en ai plus besoin. En Windev, rien ne va sans
declaration dans l'analyse. Ce qui me fache encore plus à cause de ce
système primitif c'est que j'ai été obligé de passer les données du
groupware utilisateur français à celui anglais car PCS n'était pas
capable de les faire comptabiles. Développer 10 fois plus vite: mon
oeil!!! Peut-être pour les projets entièrement compatible avec le RAD.


J'utilise et je veux continuer d'utiliser HF mais que je n'en suis pas
satisfait pour le moment. Il y a du mieux sur le marché faisant
partie de produits d'un niveau de prix bien plus bas que celui de
Windev. N'est-ce pas une motivation pour améliorer HF?

dans (in) fr.comp.developpement.agl.windev, mat
<NoSpam-mnobs@bluemail.ch> ecrivait (wrote) :

Bonjour,

Article très documenté et intéressant, merci Mat.

Juste sur ce point :

Alors, ne serait-il pas mieux d'améliorer Windev/HF au lieu de continuer
à proposer des béquilles?

Ayant eu l'occasion d'utiliser d'autres bases de données que HF, et
tentant depuis un an d'utiliser HF (sur une machine FreeBSD avec Samba,
pourtant plus fiable, rapide et efficace qu'un serveur Windows) sur un
accès distant en VPN (1024/256 quand même, mais on est loin des 100 mbps
symétriques en réseau local), force est de constater que c'est
_totalement_ inutilisable.

Cela fait un an que mon client râle et j'ai tout essayé (limiter les
ouvertures/fermetures de fichiers, utiliser des vues, limiter au maximum
l'utilisation de clés composées) rien n'y fait, et à part mettre en
place une solution basée sur Citrix (d'où acquisition de compétences
lourdes et de licences hors de prix ainsi que d'un serveur sous Windows,
toutes choses pour lesquelles le client refuse de payer, à juste titre à
mon avis), je ne vois aucune solution viable.

Résultat des courses, comme migrer les bases de données de l'application
sous MySQL nous coûterait trop cher en développemet à cause de la taille
et de la complexité de l'application (plus de 10 ans de développement,
j'ai commencé à la développer avec Windev 1 en 1992 sur un 286) et des
particularités de HF, bien pratiques sur le moment mais compliquant la
migration (les champs tableau dans les enregistrements pour ne donner
qu'un exemple), j'ai réussi à vendre (enfin vendre, c'est beaucoup dire,
faire accepter la migration à mes frais en fait) au client l'idée
d'abandonner l'accès distant partagé à la base en temps réel au profit
d'une synchronisation quotidienne de bases en local par l'échange de
fichiers textes transmis en FTP ou par courrier électronique, malgré
tous les risques que comporte une telle solution en matière d'intégrité
et de cohérence des données.

Donc nous allons développer à nos frais une usine à gaz (qui nous
coûtera moins cher que de jeter HF (mais qui nous coûtera cher quand
même) et perdre tout le bénéfice qu'il y a à travailler en temps réel
sur une base de données partagée parce que HF est totalement inadapté à
cet usage en accès distant, quoi qu'en dise Pc-Soft, qui en passant nous
promet depuis des années une _vraie_ version client serveur, après nous
avoir fait croire pendant des années aussi que HF était client-serveur
alors qu'elle ne l'est pas, d'où les broadcasts de folie en réseau, qui
peuvent passer en local mais certainement pas en distant, à moins de
disposer d'une bande passante délirante.

Bien sur, si HF s'avérait réellement client/serveur, à savoir capable de
recevoir des requêtes, de les traiter sur le serveur, puis de renvoyer
_uniquement_ les résultats, ça améliorerait grandement les choses, mais
pour l'instant ce n'est toujours pas le cas.

Pour conclure sur une note positive, je trouve que Windev est par
ailleurs un superbe outil de développement, et que s'il n'y avait pas
ces problèmes avec HF (j'allais oublier le célèbre accès en ODBC limité
en lecture seule « pour raisons de sécurité (sic) », je ne l'aurais pas,
et ce fut avec bien des regrets, abandonné.

Reste que quand on a des clients, il faut maintenir l'existant, et que
maintenant, j'ai l'impression d'avoir un boulet au pied pour avoir cru
en Windev et l'avoir utilisé si longtemps. Bizarre manière de fidéliser
ses clients. Efficace, mais bizarre.

--
Eric