Tojours mes recherches sur SQL sur HF (format 5.5)
Je cherche à récupérer les articles constituants d'un ensemble (pour
l'exemple ici son identifiant est 3863)
Table ARTCONST
ENSEMBLE entier (clé primaire identifiant ensemble)
ARCLEUNIK entier (clé identifiant article)
NUMERO entier (clé identifiant article - pour gérer les équivalences (pas
utilisé dans l'exemple))
NUMCONST ...
etc...
Voici la requete:
select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST, ARTCONST.QTE,
ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV,
ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION
from ARTCONST ARTCONST, ARTICLES ARTICLES
where (ARTCONST.ENSEMBLE = 3863)
and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK)
Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!!
En passant par des vues, c'est de l'ordre de moins d'une seconde !
Ai-je mal concu ma requete (pourtant simple) ?
Merci à tous
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
elecoest
Bonjour,
Tojours mes recherches sur SQL sur HF (format 5.5) Je cherche à récupérer les articles constituants d'un ensemble (pour l'exemple ici son identifiant est 3863)
[CUT]
Voici la requete: select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST,
ARTCONST.QTE,
ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV, ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION from ARTCONST ARTCONST, ARTICLES ARTICLES where (ARTCONST.ENSEMBLE = 3863) and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK)
Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!!
As-tu fait un OptimiseRequete avant l'exécution de celle-ci ? Pour info, ce n'est pas tant le nombre de lignes renvoyées qui prend du temps dans une requete mais l'exécution de son plan d'exécution et la recherche des données en base.
En passant par des vues, c'est de l'ordre de moins d'une seconde !
Cela confiormerait que la requete n'a pas été optimisée. Par contre je ne sais pas si sur des fichiers HF5 tu peux optimiser...
Ai-je mal concu ma requete (pourtant simple) ?
Non, elle tient la route, tu filtres à mort sur une PK et tu joints avec un table sur une FK.
-- Emmanuel
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
Bonjour,
Tojours mes recherches sur SQL sur HF (format 5.5)
Je cherche à récupérer les articles constituants d'un ensemble (pour
l'exemple ici son identifiant est 3863)
[CUT]
Voici la requete:
select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST,
ARTCONST.QTE,
ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV,
ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION
from ARTCONST ARTCONST, ARTICLES ARTICLES
where (ARTCONST.ENSEMBLE = 3863)
and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK)
Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!!
As-tu fait un OptimiseRequete avant l'exécution de celle-ci ? Pour info, ce
n'est pas tant le nombre de lignes renvoyées qui prend du temps dans une
requete mais l'exécution de son plan d'exécution et la recherche des données
en base.
En passant par des vues, c'est de l'ordre de moins d'une seconde !
Cela confiormerait que la requete n'a pas été optimisée. Par contre je ne
sais pas si sur des fichiers HF5 tu peux optimiser...
Ai-je mal concu ma requete (pourtant simple) ?
Non, elle tient la route, tu filtres à mort sur une PK et tu joints avec un
table sur une FK.
--
Emmanuel
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
Tojours mes recherches sur SQL sur HF (format 5.5) Je cherche à récupérer les articles constituants d'un ensemble (pour l'exemple ici son identifiant est 3863)
[CUT]
Voici la requete: select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST,
ARTCONST.QTE,
ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV, ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION from ARTCONST ARTCONST, ARTICLES ARTICLES where (ARTCONST.ENSEMBLE = 3863) and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK)
Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!!
As-tu fait un OptimiseRequete avant l'exécution de celle-ci ? Pour info, ce n'est pas tant le nombre de lignes renvoyées qui prend du temps dans une requete mais l'exécution de son plan d'exécution et la recherche des données en base.
En passant par des vues, c'est de l'ordre de moins d'une seconde !
Cela confiormerait que la requete n'a pas été optimisée. Par contre je ne sais pas si sur des fichiers HF5 tu peux optimiser...
Ai-je mal concu ma requete (pourtant simple) ?
Non, elle tient la route, tu filtres à mort sur une PK et tu joints avec un table sur une FK.
-- Emmanuel
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
I.G.LOG
Merci Emmanuel Je vais essayer OptimiseRequete et te communique le resultat
"elecoest" a écrit dans le message de news:c5o62t$sod$
Bonjour,
> Tojours mes recherches sur SQL sur HF (format 5.5) > Je cherche à récupérer les articles constituants d'un ensemble (pour > l'exemple ici son identifiant est 3863)
[CUT]
> Voici la requete: > select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST, ARTCONST.QTE, > ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV, > ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION > from ARTCONST ARTCONST, ARTICLES ARTICLES > where (ARTCONST.ENSEMBLE = 3863) > and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK) > > Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!!
As-tu fait un OptimiseRequete avant l'exécution de celle-ci ? Pour info,
ce
n'est pas tant le nombre de lignes renvoyées qui prend du temps dans une requete mais l'exécution de son plan d'exécution et la recherche des
données
en base.
> En passant par des vues, c'est de l'ordre de moins d'une seconde !
Cela confiormerait que la requete n'a pas été optimisée. Par contre je ne sais pas si sur des fichiers HF5 tu peux optimiser...
> Ai-je mal concu ma requete (pourtant simple) ?
Non, elle tient la route, tu filtres à mort sur une PK et tu joints avec
un
table sur une FK.
-- Emmanuel
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
Merci Emmanuel
Je vais essayer OptimiseRequete et te communique le resultat
"elecoest" <elecoest@wanadoo.fr> a écrit dans le message de
news:c5o62t$sod$1@news-reader1.wanadoo.fr...
Bonjour,
> Tojours mes recherches sur SQL sur HF (format 5.5)
> Je cherche à récupérer les articles constituants d'un ensemble (pour
> l'exemple ici son identifiant est 3863)
[CUT]
> Voici la requete:
> select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST,
ARTCONST.QTE,
> ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV,
> ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION
> from ARTCONST ARTCONST, ARTICLES ARTICLES
> where (ARTCONST.ENSEMBLE = 3863)
> and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK)
>
> Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!!
As-tu fait un OptimiseRequete avant l'exécution de celle-ci ? Pour info,
ce
n'est pas tant le nombre de lignes renvoyées qui prend du temps dans une
requete mais l'exécution de son plan d'exécution et la recherche des
données
en base.
> En passant par des vues, c'est de l'ordre de moins d'une seconde !
Cela confiormerait que la requete n'a pas été optimisée. Par contre je ne
sais pas si sur des fichiers HF5 tu peux optimiser...
> Ai-je mal concu ma requete (pourtant simple) ?
Non, elle tient la route, tu filtres à mort sur une PK et tu joints avec
un
table sur une FK.
--
Emmanuel
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
Merci Emmanuel Je vais essayer OptimiseRequete et te communique le resultat
"elecoest" a écrit dans le message de news:c5o62t$sod$
Bonjour,
> Tojours mes recherches sur SQL sur HF (format 5.5) > Je cherche à récupérer les articles constituants d'un ensemble (pour > l'exemple ici son identifiant est 3863)
[CUT]
> Voici la requete: > select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST, ARTCONST.QTE, > ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV, > ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION > from ARTCONST ARTCONST, ARTICLES ARTICLES > where (ARTCONST.ENSEMBLE = 3863) > and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK) > > Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!!
As-tu fait un OptimiseRequete avant l'exécution de celle-ci ? Pour info,
ce
n'est pas tant le nombre de lignes renvoyées qui prend du temps dans une requete mais l'exécution de son plan d'exécution et la recherche des
données
en base.
> En passant par des vues, c'est de l'ordre de moins d'une seconde !
Cela confiormerait que la requete n'a pas été optimisée. Par contre je ne sais pas si sur des fichiers HF5 tu peux optimiser...
> Ai-je mal concu ma requete (pourtant simple) ?
Non, elle tient la route, tu filtres à mort sur une PK et tu joints avec
un
table sur une FK.
-- Emmanuel
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
I.G.LOG
Je voudrais, en plus des constituants d'ensemble, gérer les equivalences d'articles (en se basant sur la cle NUMERO de la table ARTCONST - le couple ARCLEUNIKet NUMERO donne les equivalences à une article)
Table ARTCONST ENSEMBLE entier (clé primaire identifiant ensemble) ARCLEUNIK entier (clé identifiant article) NUMERO entier (clé identifiant article - pour gérer les équivalences) NUMCONST ... etc...
Voic la requete qui affiche une erreur "erreur d'intialisation de la requete" puis "70208":
select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST, ARTCONST.QTE, ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV, ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION, EQUIVAL.ABRCONST as EquABRCONST, EQUIVAL.REFCONST as EquREFCONST, EQUIVAL.DESIGNATION as EquDESIGNATION from ARTCONST ARTCONST, ARTICLES ARTICLES, ARTCONST left outer join ARTICLES EQUIVAL on EQUIVAL.ARCLEUNIK ARTCONST.NUMERO where (ARTCONST.ENSEMBLE = {pNumEns}) and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK)
Pour mieux comprendre, une liste exemple d'ensemble/articles/equivalences: GATEAU - FARINE GATEAU - SUCRE (sucre est le constituant "standard") GATEAU - SUCRE - SACCHAROSE (saccharose à la place du sucre suivant recommandation médecin) GATEAU - EAU GATEAU - EAU - VIN (pour les amateurs on peut mettre du vin à la place de l'eau :-) GATEAU - LAIT GATEAU - CERISE etc...
Merci encore pour vos conseils
Je voudrais, en plus des constituants d'ensemble, gérer les equivalences
d'articles (en se basant sur la cle NUMERO de la table ARTCONST - le couple
ARCLEUNIKet NUMERO donne les equivalences à une article)
Table ARTCONST
ENSEMBLE entier (clé primaire identifiant ensemble)
ARCLEUNIK entier (clé identifiant article)
NUMERO entier (clé identifiant article - pour gérer les équivalences)
NUMCONST ...
etc...
Voic la requete qui affiche une erreur "erreur d'intialisation de la
requete" puis "70208":
select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST, ARTCONST.QTE,
ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV,
ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION,
EQUIVAL.ABRCONST as EquABRCONST, EQUIVAL.REFCONST as EquREFCONST,
EQUIVAL.DESIGNATION as EquDESIGNATION
from ARTCONST ARTCONST, ARTICLES ARTICLES,
ARTCONST left outer join ARTICLES EQUIVAL on EQUIVAL.ARCLEUNIK ARTCONST.NUMERO
where (ARTCONST.ENSEMBLE = {pNumEns})
and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK)
Pour mieux comprendre, une liste exemple d'ensemble/articles/equivalences:
GATEAU - FARINE
GATEAU - SUCRE (sucre est le constituant "standard")
GATEAU - SUCRE - SACCHAROSE (saccharose à la place du sucre suivant
recommandation médecin)
GATEAU - EAU
GATEAU - EAU - VIN (pour les amateurs on peut mettre du vin à la place de
l'eau :-)
GATEAU - LAIT
GATEAU - CERISE
etc...
Je voudrais, en plus des constituants d'ensemble, gérer les equivalences d'articles (en se basant sur la cle NUMERO de la table ARTCONST - le couple ARCLEUNIKet NUMERO donne les equivalences à une article)
Table ARTCONST ENSEMBLE entier (clé primaire identifiant ensemble) ARCLEUNIK entier (clé identifiant article) NUMERO entier (clé identifiant article - pour gérer les équivalences) NUMCONST ... etc...
Voic la requete qui affiche une erreur "erreur d'intialisation de la requete" puis "70208":
select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST, ARTCONST.QTE, ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV, ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION, EQUIVAL.ABRCONST as EquABRCONST, EQUIVAL.REFCONST as EquREFCONST, EQUIVAL.DESIGNATION as EquDESIGNATION from ARTCONST ARTCONST, ARTICLES ARTICLES, ARTCONST left outer join ARTICLES EQUIVAL on EQUIVAL.ARCLEUNIK ARTCONST.NUMERO where (ARTCONST.ENSEMBLE = {pNumEns}) and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK)
Pour mieux comprendre, une liste exemple d'ensemble/articles/equivalences: GATEAU - FARINE GATEAU - SUCRE (sucre est le constituant "standard") GATEAU - SUCRE - SACCHAROSE (saccharose à la place du sucre suivant recommandation médecin) GATEAU - EAU GATEAU - EAU - VIN (pour les amateurs on peut mettre du vin à la place de l'eau :-) GATEAU - LAIT GATEAU - CERISE etc...
Merci encore pour vos conseils
I.G.LOG
J'ai utilisé HOptimiseRequete mais les temps sont les mêmes !!! Donc il semblerait que les performances SQL sur HF ne soient pas au rendez-vous; bien inquiétant tout de même !
Au passage, petite info sur HOptimiseRequete: il semblerait que cette fonction utilisée sur une requete paramétrée modifie le paramètre (?!):
Constit.pNumEns = gArt:Ident HOptimiseRequête(Constit) HExécuteRequête(Constit) HLitPremier(Constit) TANTQUE PAS HEnDehors() Trace(SansEspace(Constit.ABRCONST)+"-"+Constit.REFCONST+" syst="+Constit.SYSTEMATIQUE) HLitSuivant(Constit) FIN me donne 7302 enregsitrements (faux !!!!)
Le même code sans HOptimiseRequête:
Constit.pNumEns = gArt:Ident HExécuteRequête(Constit) HLitPremier(Constit) TANTQUE PAS HEnDehors() Trace(SansEspace(Constit.ABRCONST)+"-"+Constit.REFCONST+" syst="+Constit.SYSTEMATIQUE) HLitSuivant(Constit) FIN me donne 70 enregistrements (juste)
"elecoest" a écrit dans le message de news:c5o62t$sod$
Bonjour,
> Tojours mes recherches sur SQL sur HF (format 5.5) > Je cherche à récupérer les articles constituants d'un ensemble (pour > l'exemple ici son identifiant est 3863)
[CUT]
> Voici la requete: > select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST, ARTCONST.QTE, > ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV, > ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION > from ARTCONST ARTCONST, ARTICLES ARTICLES > where (ARTCONST.ENSEMBLE = 3863) > and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK) > > Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!!
As-tu fait un OptimiseRequete avant l'exécution de celle-ci ? Pour info,
ce
n'est pas tant le nombre de lignes renvoyées qui prend du temps dans une requete mais l'exécution de son plan d'exécution et la recherche des
données
en base.
> En passant par des vues, c'est de l'ordre de moins d'une seconde !
Cela confiormerait que la requete n'a pas été optimisée. Par contre je ne sais pas si sur des fichiers HF5 tu peux optimiser...
> Ai-je mal concu ma requete (pourtant simple) ?
Non, elle tient la route, tu filtres à mort sur une PK et tu joints avec
un
table sur une FK.
-- Emmanuel
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
J'ai utilisé HOptimiseRequete mais les temps sont les mêmes !!!
Donc il semblerait que les performances SQL sur HF ne soient pas au
rendez-vous; bien inquiétant tout de même !
Au passage, petite info sur HOptimiseRequete: il semblerait que cette
fonction utilisée sur une requete paramétrée modifie le paramètre (?!):
Constit.pNumEns = gArt:Ident
HOptimiseRequête(Constit)
HExécuteRequête(Constit)
HLitPremier(Constit)
TANTQUE PAS HEnDehors()
Trace(SansEspace(Constit.ABRCONST)+"-"+Constit.REFCONST+"
syst="+Constit.SYSTEMATIQUE)
HLitSuivant(Constit)
FIN
me donne 7302 enregsitrements (faux !!!!)
Le même code sans HOptimiseRequête:
Constit.pNumEns = gArt:Ident
HExécuteRequête(Constit)
HLitPremier(Constit)
TANTQUE PAS HEnDehors()
Trace(SansEspace(Constit.ABRCONST)+"-"+Constit.REFCONST+"
syst="+Constit.SYSTEMATIQUE)
HLitSuivant(Constit)
FIN
me donne 70 enregistrements (juste)
"elecoest" <elecoest@wanadoo.fr> a écrit dans le message de
news:c5o62t$sod$1@news-reader1.wanadoo.fr...
Bonjour,
> Tojours mes recherches sur SQL sur HF (format 5.5)
> Je cherche à récupérer les articles constituants d'un ensemble (pour
> l'exemple ici son identifiant est 3863)
[CUT]
> Voici la requete:
> select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST,
ARTCONST.QTE,
> ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV,
> ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION
> from ARTCONST ARTCONST, ARTICLES ARTICLES
> where (ARTCONST.ENSEMBLE = 3863)
> and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK)
>
> Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!!
As-tu fait un OptimiseRequete avant l'exécution de celle-ci ? Pour info,
ce
n'est pas tant le nombre de lignes renvoyées qui prend du temps dans une
requete mais l'exécution de son plan d'exécution et la recherche des
données
en base.
> En passant par des vues, c'est de l'ordre de moins d'une seconde !
Cela confiormerait que la requete n'a pas été optimisée. Par contre je ne
sais pas si sur des fichiers HF5 tu peux optimiser...
> Ai-je mal concu ma requete (pourtant simple) ?
Non, elle tient la route, tu filtres à mort sur une PK et tu joints avec
un
table sur une FK.
--
Emmanuel
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
J'ai utilisé HOptimiseRequete mais les temps sont les mêmes !!! Donc il semblerait que les performances SQL sur HF ne soient pas au rendez-vous; bien inquiétant tout de même !
Au passage, petite info sur HOptimiseRequete: il semblerait que cette fonction utilisée sur une requete paramétrée modifie le paramètre (?!):
Constit.pNumEns = gArt:Ident HOptimiseRequête(Constit) HExécuteRequête(Constit) HLitPremier(Constit) TANTQUE PAS HEnDehors() Trace(SansEspace(Constit.ABRCONST)+"-"+Constit.REFCONST+" syst="+Constit.SYSTEMATIQUE) HLitSuivant(Constit) FIN me donne 7302 enregsitrements (faux !!!!)
Le même code sans HOptimiseRequête:
Constit.pNumEns = gArt:Ident HExécuteRequête(Constit) HLitPremier(Constit) TANTQUE PAS HEnDehors() Trace(SansEspace(Constit.ABRCONST)+"-"+Constit.REFCONST+" syst="+Constit.SYSTEMATIQUE) HLitSuivant(Constit) FIN me donne 70 enregistrements (juste)
"elecoest" a écrit dans le message de news:c5o62t$sod$
Bonjour,
> Tojours mes recherches sur SQL sur HF (format 5.5) > Je cherche à récupérer les articles constituants d'un ensemble (pour > l'exemple ici son identifiant est 3863)
[CUT]
> Voici la requete: > select ARTCONST.ARCLEUNIK, ARTCONST.NUMERO, ARTCONST.NUMCONST, ARTCONST.QTE, > ARTCONST.SYSTEMATIQUE, ARTCONST.TERMINE, ARTCONST.OBSERV, > ARTICLES.ABRCONST, ARTICLES.REFCONST, ARTICLES.DESIGNATION > from ARTCONST ARTCONST, ARTICLES ARTICLES > where (ARTCONST.ENSEMBLE = 3863) > and (ARTICLES.ARCLEUNIK = ARTCONST.ARCLEUNIK) > > Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!!
As-tu fait un OptimiseRequete avant l'exécution de celle-ci ? Pour info,
ce
n'est pas tant le nombre de lignes renvoyées qui prend du temps dans une requete mais l'exécution de son plan d'exécution et la recherche des
données
en base.
> En passant par des vues, c'est de l'ordre de moins d'une seconde !
Cela confiormerait que la requete n'a pas été optimisée. Par contre je ne sais pas si sur des fichiers HF5 tu peux optimiser...
> Ai-je mal concu ma requete (pourtant simple) ?
Non, elle tient la route, tu filtres à mort sur une PK et tu joints avec
un
table sur une FK.
-- Emmanuel
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
elecoest
> J'ai utilisé HOptimiseRequete mais les temps sont les mêmes !!! Donc il semblerait que les performances SQL sur HF ne soient pas au rendez-vous; bien inquiétant tout de même !
Faire du SQL sur du HF5 à partir de WD8 c'est quand même la meilleure config pour les temps de réponses. Je pense même que cela n'influe en rien de faire un OptimiseRequete vu que c'est une fonctionnalité WD7 qui met à jour les poids dans les différents fichiers HF7...
Désolé, soit tu passes en HF7 soit tu continue avec tes vues et filtres.
-- Emmanuel
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
> J'ai utilisé HOptimiseRequete mais les temps sont les mêmes !!!
Donc il semblerait que les performances SQL sur HF ne soient pas au
rendez-vous; bien inquiétant tout de même !
Faire du SQL sur du HF5 à partir de WD8 c'est quand même la meilleure config
pour les temps de réponses.
Je pense même que cela n'influe en rien de faire un OptimiseRequete vu que
c'est une fonctionnalité WD7 qui met à jour les poids dans les différents
fichiers HF7...
Désolé, soit tu passes en HF7 soit tu continue avec tes vues et filtres.
--
Emmanuel
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
> J'ai utilisé HOptimiseRequete mais les temps sont les mêmes !!! Donc il semblerait que les performances SQL sur HF ne soient pas au rendez-vous; bien inquiétant tout de même !
Faire du SQL sur du HF5 à partir de WD8 c'est quand même la meilleure config pour les temps de réponses. Je pense même que cela n'influe en rien de faire un OptimiseRequete vu que c'est une fonctionnalité WD7 qui met à jour les poids dans les différents fichiers HF7...
Désolé, soit tu passes en HF7 soit tu continue avec tes vues et filtres.
-- Emmanuel
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.618 / Virus Database: 397 - Release Date: 09/03/2004
mat
I.G.LOG wrote:
Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!! En passant par des vues, c'est de l'ordre de moins d'une seconde ! Ai-je mal concu ma requete (pourtant simple) ? Merci à tous
Des fois des sous-requêtes donnent de meilleures performances. Voir les posts sur la ML Windev-Forum [WD8] Performance requète SQL sur HF.
I.G.LOG wrote:
Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!!
En passant par des vues, c'est de l'ordre de moins d'une seconde !
Ai-je mal concu ma requete (pourtant simple) ?
Merci à tous
Des fois des sous-requêtes donnent de meilleures performances. Voir les
posts sur la ML Windev-Forum [WD8] Performance requète SQL sur HF.
Elle s'exécute en 30,69 secondes pour un résultat de 70 lignes !!!!!!! En passant par des vues, c'est de l'ordre de moins d'une seconde ! Ai-je mal concu ma requete (pourtant simple) ? Merci à tous
Des fois des sous-requêtes donnent de meilleures performances. Voir les posts sur la ML Windev-Forum [WD8] Performance requète SQL sur HF.
