|
FOROS PROFESIONALES
WINDEV, WEBDEV y WINDEV Mobile |
| | | | | |
| Iniciado por laudenr, 27,oct. 2004 17:46 - 5 respuestas |
| |
| | | |
|
| |
| Publicado el 27,octubre 2004 - 17:46 |
bonjour à tous
j'ai une application en 7.5
Sur une procédure du type suivant:
Hlitpremier(Historiqueclient,cle1)
hlitrecherche(client,cle1) ... pour avoir le nom du client
hlitrecherche(article,cle1) ... pour avoir le nom de l'article
Hlitsuivant(Historiqueclient,cle1)
le temps de réponse en mode fichier HyperFile est correct 3000 enregs
traités en +2secondes
j'ai passé la base HyperFile en table SQL SERVER (demande du client
final)
j'utilise l'accès natif SQL SERVER
J'ai gardé le même code source (langage Hlitpremier Hlitsuivant etc ...)
le temps de réponse est de +30secondes !!!! ...
Si j'enlève les Hlitrecherche de la boucle hlitpremier/hlitsuivant
le temps de réponse est de nouveau de 2 secondes mais évidemment je n'ai
plus le même résultat (absence nom client/nom article)
Si je change de langage
j'utilise du SQL "SELECT Historiqueclient , avec jointures client , article ..."
je retrouve le temps de réponse de 2 secondes
mais je cela m'oblige à changer mes hlit par des SELECT !!!!
Comme je souhaite garder le langage de base de l'application (Hlit
etc..) pour gagner du temps de migration
Comment faire en sql server pour retrouver le temps de réponse
7.5 hyperfile sans remettre totalement en cause le langage de base??
merci à tous |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,octubre 2004 - 18:05 |
c'est effectivement la question que je me toujours suis posée, comment des
fonctions HF pouvaient remplacer des requetes SQL...
Je ne veux pas m'avancer mais tu as du te tromper dans le titre, c pas
lenteur sql server mais lenteur HF
"bob lauden" <laudenr@cricsa.com> a écrit dans le message de
news:417f9d55@news.pcsoft.fr...
bonjour à tous
j'ai une application en 7.5
Sur une procédure du type suivant:
Hlitpremier(Historiqueclient,cle1)
hlitrecherche(client,cle1) ... pour avoir le nom du client
hlitrecherche(article,cle1) ... pour avoir le nom de
l'article
Hlitsuivant(Historiqueclient,cle1)
le temps de réponse en mode fichier HyperFile est correct 3000 enregs
traités en +2secondes
j'ai passé la base HyperFile en table SQL SERVER (demande du client
final)
j'utilise l'accès natif SQL SERVER
J'ai gardé le même code source (langage Hlitpremier Hlitsuivant etc
....)
le temps de réponse est de +30secondes !!!! ...
Si j'enlève les Hlitrecherche de la boucle hlitpremier/hlitsuivant
le temps de réponse est de nouveau de 2 secondes mais évidemment je n'ai
plus le même résultat (absence nom client/nom article)
Si je change de langage
j'utilise du SQL "SELECT Historiqueclient , avec jointures client ,
article ..."
je retrouve le temps de réponse de 2 secondes
mais je cela m'oblige à changer mes hlit par des SELECT !!!!
Comme je souhaite garder le langage de base de l'application (Hlit
etc..) pour gagner du temps de migration
Comment faire en sql server pour retrouver le temps de réponse
7.5 hyperfile sans remettre totalement en cause le langage de base??
merci à tous
|
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,octubre 2004 - 18:53 |
Pour rester sérieux, je ne vois pas comment un hlitrecherche() suivit de
hlitsuivant() peut être plus rapide qu'une requete
en fait je pense qu'il y aura autant de requetes que de hlitsuivant()
il vaut mieux utiliser des hfiltre()
"bob lauden" <laudenr@cricsa.com> a écrit dans le message de
news:417f9d55@news.pcsoft.fr...
bonjour à tous
j'ai une application en 7.5
Sur une procédure du type suivant:
Hlitpremier(Historiqueclient,cle1)
hlitrecherche(client,cle1) ... pour avoir le nom du client
hlitrecherche(article,cle1) ... pour avoir le nom de
l'article
Hlitsuivant(Historiqueclient,cle1)
le temps de réponse en mode fichier HyperFile est correct 3000 enregs
traités en +2secondes
j'ai passé la base HyperFile en table SQL SERVER (demande du client
final)
j'utilise l'accès natif SQL SERVER
J'ai gardé le même code source (langage Hlitpremier Hlitsuivant etc
....)
le temps de réponse est de +30secondes !!!! ...
Si j'enlève les Hlitrecherche de la boucle hlitpremier/hlitsuivant
le temps de réponse est de nouveau de 2 secondes mais évidemment je n'ai
plus le même résultat (absence nom client/nom article)
Si je change de langage
j'utilise du SQL "SELECT Historiqueclient , avec jointures client ,
article ..."
je retrouve le temps de réponse de 2 secondes
mais je cela m'oblige à changer mes hlit par des SELECT !!!!
Comme je souhaite garder le langage de base de l'application (Hlit
etc..) pour gagner du temps de migration
Comment faire en sql server pour retrouver le temps de réponse
7.5 hyperfile sans remettre totalement en cause le langage de base??
merci à tous
|
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,octubre 2004 - 18:55 |
Bonjour,
Pour que ton application fonctionne efficacement, la première chose à
assimiler est que SQL n'a rien à voir avec les ordres H*.
SQL lance un query sur le serveur et attend un réponse. H* fait le boulot
lui-même. H* est donc 10 fois plus rapide sur du HF que sur du SQL Server.
Et c'est tout naturel !
La règle d'or de SQL est pour moi la suivante :
Ce qui tue SQL Server est non pas la complexité des requêtes que tu fais
mais uniquement la cadence de tes requetes.
Imagine un instant que tu as normalement 200 lignes de réponses qui doivent
provenir de ton fichier Historique. En réalité, tu fais 400 accès vers ton
serveur et tu as 400 retours. Total 800. Sans oublier que comme on ne sait
pas ce que tu vas utiliser comme champ, TOUT est rapatrié à chaque fois.
En SQL, on passe à 2. Envoi du query, récupération de la réponse qui
contient tes enregistrements avec uniquement les champs dont tu as besoin..
Les modifs de code sont donc inévitables...
Pour gagner du temps lors de la migration, déclare une source de donnée
XXhisto et fait un hexecuterequeteSQL dans laquelle tu fais un SELECT dans
historiqueclient et article avec un JOIN.
Tu modifies ensuite tes appels de type variable=Hitoriqueclient.nomclient et
article.codearticle par
XXHisto.nomclient et XXHisto.codearticle
Tu auras donc
XXHisto est une source de donnees
ExecuteRequeteSQL("XXHISTO","Select ....INNER JOIN...")
HLITPREMIER(XXHISTO)
TANTQUE pas hendehors()
//Traitement
HLITSUIVANT(XXHISTO)
FIN
Si tu désires placer le résultat directement dans une table, utilise plutôt
le code ci-après (nous utilisons cela sans arrêt)
Query is string
QUERY="MyQuery"
IF NOT SQLExec(QUERY,"CASSOU") THEN
SQLInfo("CASSOU")
Error(MessTraduit(333)+" "+ SQL.MesError+CR+SQL.Error)
END
SQLTable("CASSOU","TABLE")
SQLClose("CASSOU")
Cela écrase n'importe lequel des parcours "classique" de type HLit* en temps
de réponse.
Bon amusement,
Benoit
"bob lauden" <laudenr@cricsa.com> a écrit dans le message de news:
417f9d55@news.pcsoft.fr...
bonjour à tous
j'ai une application en 7.5
Sur une procédure du type suivant:
Hlitpremier(Historiqueclient,cle1)
hlitrecherche(client,cle1) ... pour avoir le nom du client
hlitrecherche(article,cle1) ... pour avoir le nom de
l'article
Hlitsuivant(Historiqueclient,cle1)
le temps de réponse en mode fichier HyperFile est correct 3000 enregs
traités en +2secondes
j'ai passé la base HyperFile en table SQL SERVER (demande du client
final)
j'utilise l'accès natif SQL SERVER
J'ai gardé le même code source (langage Hlitpremier Hlitsuivant etc ...)
le temps de réponse est de +30secondes !!!! ...
Si j'enlève les Hlitrecherche de la boucle hlitpremier/hlitsuivant
le temps de réponse est de nouveau de 2 secondes mais évidemment je n'ai
plus le même résultat (absence nom client/nom article)
Si je change de langage
j'utilise du SQL "SELECT Historiqueclient , avec jointures client ,
article ..."
je retrouve le temps de réponse de 2 secondes
mais je cela m'oblige à changer mes hlit par des SELECT !!!!
Comme je souhaite garder le langage de base de l'application (Hlit
etc..) pour gagner du temps de migration
Comment faire en sql server pour retrouver le temps de réponse
7.5 hyperfile sans remettre totalement en cause le langage de base??
merci à tous
|
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,octubre 2004 - 20:56 |
Merci Pierre et Benoit
Pour Pierre: j'ai déja essayé avec hfiltre ... ça ne change pas grand chose
je pense que Benoit est plus proche de la vérité (malheureusement pour moi)
Pour Benoit:
si j'ai bien compris
Pour gagner en temps de réponse il faut modifier les codes hlit en select en respectant
les jointures
1er problème ... je ne suis pas un "pro" du langage SQL ...
beaucoup de boucles hlitpremier/hlitsuivant avec à l'intérieur des procédures de
hlitrecherche ... nombreux accés à différentes tables (jointures ??) ... bref du boulot !
2me problème ... cela va augmenter le temps de réalisation de la migration (pb interne)
Pour l'amélioration du temps de réponse:
je l'avais constaté dans mon exemple en utilisant ,à la place de hlit, l'ordre sql SELECT avec jointure INTERNE ... d'ailleurs à propos des jointures dés que j'utilise une jointure EXTERNE je "retombe" dans les mauvais temps de réponse ... comme hlit ... est ce vraiment normal ? ... d'après ton explication ... OUI
Comme je suis pressé j'ai essayé de garder les procédures en hlit ... avec les mauvais temps de réponse ... et je suis "tombé" dans un autre probléme en multi-utilisateurs
Dés l'instant que je simule 2 utilisateurs consultant , si on prend mon exemple, le même historique client ... a un moment donné le programme de l'un ou l'autre utilisateur se "plante" en erreur de mécanisme comme si il y avait un TIMEOUT avec la base sql server du fait du trafic
si tu as une idée ... elle serait la bienvenue ... sinon je vais commencer mes modifs hlit en SQL !!!
merci encore
PS: pour la table "QUERY" j'ai pas tout compris mais je vais m'y intéresser |
| |
| |
| | | |
|
| | |
| |
| Publicado el 28,octubre 2004 - 16:13 |
Pour gagner un peux plus de temps, l'appel à des procédure stockés reste la meilleure optimisation, pour la réalisation d'un projet, et de sa maintenance.
Le language SQL et les instructions Transact SQL sont indipensable, et facile d'accès.
bonne continuation.
PS: le chargement automatique de liste, ou table à partir de l'accès natif n'est pas super performant, mieux vaut réaliser les chargements en manuel et utiliser la fonction glien pour mémorisé/stockée/associé une clé ou un identifiant interne au système.
//
ListeAjoute("MaListe","Ma recette de cuisine"+glien("LIVRE15"))
info(Maliste) // renvoie "LIVRE15" |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|