[WD9] lenteur de la première requète Sql sur HyPerfile
13 réponses
Jean Cougnaud
Bonjour,
J'ai un petit souci au sujet des requètes Sql (hExecuteRequeteSql) sur des
fichiers hyperfile.
J'ai une fenêtre de recherche contenant une table mémoire que je remplis
avec une requète Sql sur un seul fichier. Celui-ci contient environ 10 000
enregistrements (ce qui n'est vraiment pas énorme). La première fois que je
lance la requète devant me renvoyer tout le fichier cela met au moins 20s.
Les fois suivantes cela est presque instantané et cela jusqu'à ce que je
relance mon PC.
L'analyseur de performance me donne une durée de hExecuteRequeteSql très
rapide mais c'est entre le début de l'analyseur et le hExecuteRequeteSql que
cela prend 19s. Je trouve cela étrange. On dirait qu'il initialise quelque
chose ?
Est-ce normal ?
Y a-t-il quelque chose à initialiser avant la requète pour que cela soit
rapide dès la première fois ?
J'ai justement fait un test entre les vues et les requêtes sur Hyperfile et le temps de réponse est pratiquement le même . J'ai un fichier d'environ 10 000 enregistrements et je les demande tous.
La première fois cela prend 15s et ensuite c'est 1s.
Les requêtes sur Hyperfile seraient des vues déguisées (ou inversement) ?
Cordialement
Jean
Une vue au sens hyperfile n'a rien à voir avec vue qu'on trouve dans les SGBDR. Car celà est impossible à faire sans moteur.
La vue hyperfile permet uniquement de remonter une partie des rubriques d'un fichier au lieu de la totalité d'où le gain de temps.
Concrètement si on fait sur une table de 100 champs : "select * from test" on va remonter tous les champs sur une vue avec le Champs1, Champs2 c'est la même chose que "select champs1, champs2 from test"
Pour dire que faire test de vue sur hyperfile avec une table ayant peu de champs ne sera pas parlant.
"sebNews" a écrit dans le message de news: 432ea6e6$0$14364$
Bonjour, Pour savoir, le mieux est de faire quelques tests : - Vérifier les index sur les fichiers - Avec HF mais sans le SQL - Exemple faire une vue sur HF ( HcreeVue ) à la place de d'une
requête
SQL ==> Quels sont les temps de réponse ?
Sébastien
Quel est le plus rapide normalement ?
Je n'utilise pratiquement que des Vues. Des vues sur des tables de 80 000 enregistrement avec environ 20 rubrique dont deux mémos sont rapides ( en réseau )
Par contre dans mon cas le nombre d'enregistrement restitué est faible ( quelques dizaines de ligne )
Sébastien
Tests effectués ce matin : Code : Trace(HeureVersChaîne(HeureSys()) + " - Début ") MaRequete est une Source de Données NbEnrg est un entier CmdSQL est une chaîne = // voir les tests HExécuteRequêteSQL(MaRequete,hRequêteDéfaut, CmdSQL) Trace(HeureVersChaîne(HeureSys()) + " - Fin du HexecuteRequeteSQL" ) NbEnrg = HNbEnr(MaRequete) Trace(HeureVersChaîne(HeureSys()) + " - Nb enrg : " + NbEnrg)
CmdSQL = "SELECT Refclient from client where nomclient like 'A%' order by refclient" 10:19:25:09 - Début 10:19:25:14 - Fin du HexecuteRequeteSQL 10:19:30:50 - Nb enrg : 88511 => 5 secondes
cmdSQL = "Select * from client where nomclient ]= ‘A’ order by refclient" 10:20:35:25 - Début 10:20:35:29 - Fin du HexecuteRequeteSQL 10:20:44:09 - Nb enrg : 88511 => 9 secondes (idem si utilisation d'une vue)
Where CodeAPE= ‘721Z’ chaine de 4c, indexé avec doublons 10:27:49:31 - Début 10:27:49:35 - Fin du HexecuteRequeteSQL 10:28:27:04 - Nb enrg : 6533 => 7 secondes
on ajoute 1 critére : CodePostal chaine de caractére, indexé avec doublons "SELECT count(refclient) as NbClient from client where CodeAPE='721Z' and Codepostal]='75' " 11:05:40:07 - Début 11:06:10:90 - Fin du HexecuteRequeteSQL 11:06:10:90 - Nb enrg : 1501 => 21 secondes
CmdSql = "Select Count(*) from client" 10:41:58:68 - Début 10:44:08:12 - Fin du HexecuteRequeteSQL 10:44:08:14 - Nb enrg : 925921 => 2 minutes et 10 secondes
Cmdsql = "Select Count(refclient) from client" clé unique 10:45:26:85 - Début 10:47:19:40 - Fin du HexecuteRequeteSQL 10:47:19:40 - Nb enrg : 925921 => 1 minutes et 53 secondes
Comme le montre le code ci-dessus, le temps d'affichage des résultats dans une table n'est pas pris en compte.
J'ai justement fait un test entre les vues et les requêtes sur Hyperfile et
le temps de réponse est pratiquement le même . J'ai un fichier d'environ 10
000 enregistrements et je les demande tous.
La première fois cela prend 15s et ensuite c'est 1s.
Les requêtes sur Hyperfile seraient des vues déguisées (ou inversement) ?
Cordialement
Jean
Une vue au sens hyperfile n'a rien à voir avec vue
qu'on trouve dans les SGBDR. Car celà est impossible à faire sans
moteur.
La vue hyperfile permet uniquement de remonter une partie des
rubriques d'un fichier au lieu de la totalité d'où le gain de temps.
Concrètement si on fait sur une table de 100 champs :
"select * from test" on va remonter tous les champs
sur une vue avec le Champs1, Champs2 c'est la même chose que
"select champs1, champs2 from test"
Pour dire que faire test de vue sur hyperfile avec une table ayant peu
de champs ne sera pas parlant.
"sebNews" <seb@yahoo.fr> a écrit dans le message de news:
432ea6e6$0$14364$626a14ce@news.free.fr...
Bonjour,
Pour savoir, le mieux est de faire quelques tests :
- Vérifier les index sur les fichiers
- Avec HF mais sans le SQL
- Exemple faire une vue sur HF ( HcreeVue ) à la place de d'une
requête
SQL
==> Quels sont les temps de réponse ?
Sébastien
Quel est le plus rapide normalement ?
Je n'utilise pratiquement que des Vues.
Des vues sur des tables de 80 000 enregistrement avec
environ 20 rubrique dont deux mémos sont rapides ( en réseau )
Par contre dans mon cas le nombre d'enregistrement restitué est faible
( quelques dizaines de ligne )
Sébastien
Tests effectués ce matin :
Code :
Trace(HeureVersChaîne(HeureSys()) + " - Début ")
MaRequete est une Source de Données
NbEnrg est un entier
CmdSQL est une chaîne = // voir les tests
HExécuteRequêteSQL(MaRequete,hRequêteDéfaut, CmdSQL)
Trace(HeureVersChaîne(HeureSys()) + " - Fin du HexecuteRequeteSQL" )
NbEnrg = HNbEnr(MaRequete)
Trace(HeureVersChaîne(HeureSys()) + " - Nb enrg : " + NbEnrg)
CmdSQL = "SELECT Refclient from client where nomclient like 'A%' order
by refclient"
10:19:25:09 - Début
10:19:25:14 - Fin du HexecuteRequeteSQL
10:19:30:50 - Nb enrg : 88511 => 5 secondes
cmdSQL = "Select * from client where nomclient ]= ‘A’ order by refclient"
10:20:35:25 - Début
10:20:35:29 - Fin du HexecuteRequeteSQL
10:20:44:09 - Nb enrg : 88511 => 9 secondes (idem si utilisation
d'une vue)
Where CodeAPE= ‘721Z’ chaine de 4c, indexé avec doublons
10:27:49:31 - Début
10:27:49:35 - Fin du HexecuteRequeteSQL
10:28:27:04 - Nb enrg : 6533 => 7 secondes
on ajoute 1 critére : CodePostal chaine de caractére, indexé avec doublons
"SELECT count(refclient) as NbClient from client where CodeAPE='721Z'
and Codepostal]='75' "
11:05:40:07 - Début
11:06:10:90 - Fin du HexecuteRequeteSQL
11:06:10:90 - Nb enrg : 1501 => 21 secondes
CmdSql = "Select Count(*) from client"
10:41:58:68 - Début
10:44:08:12 - Fin du HexecuteRequeteSQL
10:44:08:14 - Nb enrg : 925921 => 2 minutes et 10 secondes
Cmdsql = "Select Count(refclient) from client" clé unique
10:45:26:85 - Début
10:47:19:40 - Fin du HexecuteRequeteSQL
10:47:19:40 - Nb enrg : 925921 => 1 minutes et 53 secondes
Comme le montre le code ci-dessus, le temps d'affichage des résultats
dans une table n'est pas pris en compte.
J'ai justement fait un test entre les vues et les requêtes sur Hyperfile et le temps de réponse est pratiquement le même . J'ai un fichier d'environ 10 000 enregistrements et je les demande tous.
La première fois cela prend 15s et ensuite c'est 1s.
Les requêtes sur Hyperfile seraient des vues déguisées (ou inversement) ?
Cordialement
Jean
Une vue au sens hyperfile n'a rien à voir avec vue qu'on trouve dans les SGBDR. Car celà est impossible à faire sans moteur.
La vue hyperfile permet uniquement de remonter une partie des rubriques d'un fichier au lieu de la totalité d'où le gain de temps.
Concrètement si on fait sur une table de 100 champs : "select * from test" on va remonter tous les champs sur une vue avec le Champs1, Champs2 c'est la même chose que "select champs1, champs2 from test"
Pour dire que faire test de vue sur hyperfile avec une table ayant peu de champs ne sera pas parlant.
"sebNews" a écrit dans le message de news: 432ea6e6$0$14364$
Bonjour, Pour savoir, le mieux est de faire quelques tests : - Vérifier les index sur les fichiers - Avec HF mais sans le SQL - Exemple faire une vue sur HF ( HcreeVue ) à la place de d'une
requête
SQL ==> Quels sont les temps de réponse ?
Sébastien
Quel est le plus rapide normalement ?
Je n'utilise pratiquement que des Vues. Des vues sur des tables de 80 000 enregistrement avec environ 20 rubrique dont deux mémos sont rapides ( en réseau )
Par contre dans mon cas le nombre d'enregistrement restitué est faible ( quelques dizaines de ligne )
Sébastien
Tests effectués ce matin : Code : Trace(HeureVersChaîne(HeureSys()) + " - Début ") MaRequete est une Source de Données NbEnrg est un entier CmdSQL est une chaîne = // voir les tests HExécuteRequêteSQL(MaRequete,hRequêteDéfaut, CmdSQL) Trace(HeureVersChaîne(HeureSys()) + " - Fin du HexecuteRequeteSQL" ) NbEnrg = HNbEnr(MaRequete) Trace(HeureVersChaîne(HeureSys()) + " - Nb enrg : " + NbEnrg)
CmdSQL = "SELECT Refclient from client where nomclient like 'A%' order by refclient" 10:19:25:09 - Début 10:19:25:14 - Fin du HexecuteRequeteSQL 10:19:30:50 - Nb enrg : 88511 => 5 secondes
cmdSQL = "Select * from client where nomclient ]= ‘A’ order by refclient" 10:20:35:25 - Début 10:20:35:29 - Fin du HexecuteRequeteSQL 10:20:44:09 - Nb enrg : 88511 => 9 secondes (idem si utilisation d'une vue)
Where CodeAPE= ‘721Z’ chaine de 4c, indexé avec doublons 10:27:49:31 - Début 10:27:49:35 - Fin du HexecuteRequeteSQL 10:28:27:04 - Nb enrg : 6533 => 7 secondes
on ajoute 1 critére : CodePostal chaine de caractére, indexé avec doublons "SELECT count(refclient) as NbClient from client where CodeAPE='721Z' and Codepostal]='75' " 11:05:40:07 - Début 11:06:10:90 - Fin du HexecuteRequeteSQL 11:06:10:90 - Nb enrg : 1501 => 21 secondes
CmdSql = "Select Count(*) from client" 10:41:58:68 - Début 10:44:08:12 - Fin du HexecuteRequeteSQL 10:44:08:14 - Nb enrg : 925921 => 2 minutes et 10 secondes
Cmdsql = "Select Count(refclient) from client" clé unique 10:45:26:85 - Début 10:47:19:40 - Fin du HexecuteRequeteSQL 10:47:19:40 - Nb enrg : 925921 => 1 minutes et 53 secondes
Comme le montre le code ci-dessus, le temps d'affichage des résultats dans une table n'est pas pris en compte.
Vincent
Vincent a écrit :
Daniel a écrit :
Bonjour, "Jean Cougnaud" writes:
Bonjour,
J'ai justement fait un test entre les vues et les requêtes sur Hyperfile et le temps de réponse est pratiquement le même . J'ai un fichier d'environ 10 000 enregistrements et je les demande tous.
La première fois cela prend 15s et ensuite c'est 1s.
Les requêtes sur Hyperfile seraient des vues déguisées (ou inversement) ?
Cordialement
Jean
Une vue au sens hyperfile n'a rien à voir avec vue qu'on trouve dans les SGBDR. Car celà est impossible à faire sans moteur.
La vue hyperfile permet uniquement de remonter une partie des rubriques d'un fichier au lieu de la totalité d'où le gain de temps.
Concrètement si on fait sur une table de 100 champs : "select * from test" on va remonter tous les champs sur une vue avec le Champs1, Champs2 c'est la même chose que "select champs1, champs2 from test"
Pour dire que faire test de vue sur hyperfile avec une table ayant peu de champs ne sera pas parlant.
"sebNews" a écrit dans le message de news: 432ea6e6$0$14364$
Bonjour, Pour savoir, le mieux est de faire quelques tests : - Vérifier les index sur les fichiers - Avec HF mais sans le SQL - Exemple faire une vue sur HF ( HcreeVue ) à la place de d'une
requête
SQL ==> Quels sont les temps de réponse ?
Sébastien
Quel est le plus rapide normalement ?
Je n'utilise pratiquement que des Vues. Des vues sur des tables de 80 000 enregistrement avec environ 20 rubrique dont deux mémos sont rapides ( en réseau )
Par contre dans mon cas le nombre d'enregistrement restitué est faible ( quelques dizaines de ligne )
Sébastien
Tests effectués ce matin : Code : Trace(HeureVersChaîne(HeureSys()) + " - Début ") MaRequete est une Source de Données NbEnrg est un entier CmdSQL est une chaîne = // voir les tests HExécuteRequêteSQL(MaRequete,hRequêteDéfaut, CmdSQL) Trace(HeureVersChaîne(HeureSys()) + " - Fin du HexecuteRequeteSQL" ) NbEnrg = HNbEnr(MaRequete) Trace(HeureVersChaîne(HeureSys()) + " - Nb enrg : " + NbEnrg)
CmdSQL = "SELECT Refclient from client where nomclient like 'A%' order by refclient" 10:19:25:09 - Début 10:19:25:14 - Fin du HexecuteRequeteSQL 10:19:30:50 - Nb enrg : 88511 => 5 secondes
cmdSQL = "Select * from client where nomclient ]= ‘A’ order by refclient" 10:20:35:25 - Début 10:20:35:29 - Fin du HexecuteRequeteSQL 10:20:44:09 - Nb enrg : 88511 => 9 secondes (idem si utilisation d'une vue)
Where CodeAPE= ‘721Z’ chaine de 4c, indexé avec doublons 10:27:49:31 - Début 10:27:49:35 - Fin du HexecuteRequeteSQL 10:28:27:04 - Nb enrg : 6533 => 7 secondes
on ajoute 1 critére : CodePostal chaine de caractére, indexé avec doublons "SELECT count(refclient) as NbClient from client where CodeAPE='721Z' and Codepostal]='75' " 11:05:40:07 - Début 11:06:10:90 - Fin du HexecuteRequeteSQL 11:06:10:90 - Nb enrg : 1501 => 21 secondes
CmdSql = "Select Count(*) from client"
CmdSql = "Select Count(*) AS NbClient from client"
10:41:58:68 - Début 10:44:08:12 - Fin du HexecuteRequeteSQL 10:44:08:14 - Nb enrg : 925921 => 2 minutes et 10 secondes
Cmdsql = "Select Count(refclient) AS NbClient from client" clé unique 10:45:26:85 - Début 10:47:19:40 - Fin du HexecuteRequeteSQL 10:47:19:40 - Nb enrg : 925921 => 1 minutes et 53 secondes
Comme le montre le code ci-dessus, le temps d'affichage des résultats dans une table n'est pas pris en compte.
Petite précision : Les requêtes "select count..." n'utilise pas Hnbenrg() pour afficher le nombre d'enregistrement mais directement MaRequete.NbCLient
J'ai justement fait un test entre les vues et les requêtes sur Hyperfile et
le temps de réponse est pratiquement le même . J'ai un fichier d'environ 10
000 enregistrements et je les demande tous.
La première fois cela prend 15s et ensuite c'est 1s.
Les requêtes sur Hyperfile seraient des vues déguisées (ou inversement) ?
Cordialement
Jean
Une vue au sens hyperfile n'a rien à voir avec vue
qu'on trouve dans les SGBDR. Car celà est impossible à faire sans
moteur.
La vue hyperfile permet uniquement de remonter une partie des
rubriques d'un fichier au lieu de la totalité d'où le gain de temps.
Concrètement si on fait sur une table de 100 champs :
"select * from test" on va remonter tous les champs
sur une vue avec le Champs1, Champs2 c'est la même chose que
"select champs1, champs2 from test"
Pour dire que faire test de vue sur hyperfile avec une table ayant peu
de champs ne sera pas parlant.
"sebNews" <seb@yahoo.fr> a écrit dans le message de news:
432ea6e6$0$14364$626a14ce@news.free.fr...
Bonjour,
Pour savoir, le mieux est de faire quelques tests :
- Vérifier les index sur les fichiers
- Avec HF mais sans le SQL
- Exemple faire une vue sur HF ( HcreeVue ) à la place de d'une
requête
SQL
==> Quels sont les temps de réponse ?
Sébastien
Quel est le plus rapide normalement ?
Je n'utilise pratiquement que des Vues.
Des vues sur des tables de 80 000 enregistrement avec
environ 20 rubrique dont deux mémos sont rapides ( en réseau )
Par contre dans mon cas le nombre d'enregistrement restitué est faible
( quelques dizaines de ligne )
Sébastien
Tests effectués ce matin :
Code :
Trace(HeureVersChaîne(HeureSys()) + " - Début ")
MaRequete est une Source de Données
NbEnrg est un entier
CmdSQL est une chaîne = // voir les tests
HExécuteRequêteSQL(MaRequete,hRequêteDéfaut, CmdSQL)
Trace(HeureVersChaîne(HeureSys()) + " - Fin du HexecuteRequeteSQL" )
NbEnrg = HNbEnr(MaRequete)
Trace(HeureVersChaîne(HeureSys()) + " - Nb enrg : " + NbEnrg)
CmdSQL = "SELECT Refclient from client where nomclient like 'A%' order
by refclient"
10:19:25:09 - Début
10:19:25:14 - Fin du HexecuteRequeteSQL
10:19:30:50 - Nb enrg : 88511 => 5 secondes
cmdSQL = "Select * from client where nomclient ]= ‘A’ order by refclient"
10:20:35:25 - Début
10:20:35:29 - Fin du HexecuteRequeteSQL
10:20:44:09 - Nb enrg : 88511 => 9 secondes (idem si utilisation
d'une vue)
Where CodeAPE= ‘721Z’ chaine de 4c, indexé avec doublons
10:27:49:31 - Début
10:27:49:35 - Fin du HexecuteRequeteSQL
10:28:27:04 - Nb enrg : 6533 => 7 secondes
on ajoute 1 critére : CodePostal chaine de caractére, indexé avec doublons
"SELECT count(refclient) as NbClient from client where CodeAPE='721Z'
and Codepostal]='75' "
11:05:40:07 - Début
11:06:10:90 - Fin du HexecuteRequeteSQL
11:06:10:90 - Nb enrg : 1501 => 21 secondes
CmdSql = "Select Count(*) from client"
CmdSql = "Select Count(*) AS NbClient from client"
10:41:58:68 - Début
10:44:08:12 - Fin du HexecuteRequeteSQL
10:44:08:14 - Nb enrg : 925921 => 2 minutes et 10 secondes
Cmdsql = "Select Count(refclient) AS NbClient from client" clé unique
10:45:26:85 - Début
10:47:19:40 - Fin du HexecuteRequeteSQL
10:47:19:40 - Nb enrg : 925921 => 1 minutes et 53 secondes
Comme le montre le code ci-dessus, le temps d'affichage des résultats
dans une table n'est pas pris en compte.
Petite précision :
Les requêtes "select count..." n'utilise pas Hnbenrg() pour afficher le
nombre d'enregistrement mais directement MaRequete.NbCLient
J'ai justement fait un test entre les vues et les requêtes sur Hyperfile et le temps de réponse est pratiquement le même . J'ai un fichier d'environ 10 000 enregistrements et je les demande tous.
La première fois cela prend 15s et ensuite c'est 1s.
Les requêtes sur Hyperfile seraient des vues déguisées (ou inversement) ?
Cordialement
Jean
Une vue au sens hyperfile n'a rien à voir avec vue qu'on trouve dans les SGBDR. Car celà est impossible à faire sans moteur.
La vue hyperfile permet uniquement de remonter une partie des rubriques d'un fichier au lieu de la totalité d'où le gain de temps.
Concrètement si on fait sur une table de 100 champs : "select * from test" on va remonter tous les champs sur une vue avec le Champs1, Champs2 c'est la même chose que "select champs1, champs2 from test"
Pour dire que faire test de vue sur hyperfile avec une table ayant peu de champs ne sera pas parlant.
"sebNews" a écrit dans le message de news: 432ea6e6$0$14364$
Bonjour, Pour savoir, le mieux est de faire quelques tests : - Vérifier les index sur les fichiers - Avec HF mais sans le SQL - Exemple faire une vue sur HF ( HcreeVue ) à la place de d'une
requête
SQL ==> Quels sont les temps de réponse ?
Sébastien
Quel est le plus rapide normalement ?
Je n'utilise pratiquement que des Vues. Des vues sur des tables de 80 000 enregistrement avec environ 20 rubrique dont deux mémos sont rapides ( en réseau )
Par contre dans mon cas le nombre d'enregistrement restitué est faible ( quelques dizaines de ligne )
Sébastien
Tests effectués ce matin : Code : Trace(HeureVersChaîne(HeureSys()) + " - Début ") MaRequete est une Source de Données NbEnrg est un entier CmdSQL est une chaîne = // voir les tests HExécuteRequêteSQL(MaRequete,hRequêteDéfaut, CmdSQL) Trace(HeureVersChaîne(HeureSys()) + " - Fin du HexecuteRequeteSQL" ) NbEnrg = HNbEnr(MaRequete) Trace(HeureVersChaîne(HeureSys()) + " - Nb enrg : " + NbEnrg)
CmdSQL = "SELECT Refclient from client where nomclient like 'A%' order by refclient" 10:19:25:09 - Début 10:19:25:14 - Fin du HexecuteRequeteSQL 10:19:30:50 - Nb enrg : 88511 => 5 secondes
cmdSQL = "Select * from client where nomclient ]= ‘A’ order by refclient" 10:20:35:25 - Début 10:20:35:29 - Fin du HexecuteRequeteSQL 10:20:44:09 - Nb enrg : 88511 => 9 secondes (idem si utilisation d'une vue)
Where CodeAPE= ‘721Z’ chaine de 4c, indexé avec doublons 10:27:49:31 - Début 10:27:49:35 - Fin du HexecuteRequeteSQL 10:28:27:04 - Nb enrg : 6533 => 7 secondes
on ajoute 1 critére : CodePostal chaine de caractére, indexé avec doublons "SELECT count(refclient) as NbClient from client where CodeAPE='721Z' and Codepostal]='75' " 11:05:40:07 - Début 11:06:10:90 - Fin du HexecuteRequeteSQL 11:06:10:90 - Nb enrg : 1501 => 21 secondes
CmdSql = "Select Count(*) from client"
CmdSql = "Select Count(*) AS NbClient from client"
10:41:58:68 - Début 10:44:08:12 - Fin du HexecuteRequeteSQL 10:44:08:14 - Nb enrg : 925921 => 2 minutes et 10 secondes
Cmdsql = "Select Count(refclient) AS NbClient from client" clé unique 10:45:26:85 - Début 10:47:19:40 - Fin du HexecuteRequeteSQL 10:47:19:40 - Nb enrg : 925921 => 1 minutes et 53 secondes
Comme le montre le code ci-dessus, le temps d'affichage des résultats dans une table n'est pas pris en compte.
Petite précision : Les requêtes "select count..." n'utilise pas Hnbenrg() pour afficher le nombre d'enregistrement mais directement MaRequete.NbCLient
mat
Jean Cougnaud wrote:
Bonjour,
J'ai justement fait un test entre les vues et les requêtes sur Hyperfile et le temps de réponse est pratiquement le même . J'ai un fichier d'environ 10 000 enregistrements et je les demande tous.
La première fois cela prend 15s et ensuite c'est 1s.
Les requêtes sur Hyperfile seraient des vues déguisées (ou inversement) ?
Bonjour,
je pense il n'y a pas vraiment de différence entre vues et requêtes HF. Par contre, je pense que les requêtes HF, au moins en ce qui concerne HF classic, sont des filtres déguisés sur les fichiers. Cette liaison constante est aussi responsable des ralentissement de la requête lorsque le fichier est modifié sur un autre poste. Les requêtes d'autres produits ne montrent pas ce comportement, puisque les fichiers sont envoyés du serveur au poste et traités localement.
Les lenteurs lorsqu'il y a beaucoup d'enregistrements dans le résultat viennent du fait que le résultat est lu en mémoire, ligne par ligne. Quand un tel résultat s'affiche de suite, c'est que la structure de la requête et son entourage (fichiers et code) permettent que cela se passe en arrière plan (on peut voir le compteur dans une table fait par le RAD). Probablement, c'est aussi la raison principale pourquoi on ne peut pas lancer directement une requête dans un thread.
Les lenteurs lors d'une requête COUNT proviennent peut-être du même fait d'un filtre déguisé. Le résultat comprend tous les enregistrements sélectionnés dans la requête, ensuite hExecuteRequete renvoi simplement le total obtenu par une boucle POUR TOUS. Enfin, je ne vois nulle autre explication pour le fait que le temps de traitement dépend du nombre d'enregistrements traités ou présents dans le résultat. Malheureusement, PC Soft n'ont jamais considéré important d'informer leurs client comment fonctionne leur système de requêtes propriétaire afin de vraiment pouvoir optimiser le code. On a préféré parler de problèmes inhérent au code des développeurs ou au système d'exploitation.
Salutations Mat
Jean Cougnaud wrote:
Bonjour,
J'ai justement fait un test entre les vues et les requêtes sur Hyperfile et
le temps de réponse est pratiquement le même . J'ai un fichier d'environ 10
000 enregistrements et je les demande tous.
La première fois cela prend 15s et ensuite c'est 1s.
Les requêtes sur Hyperfile seraient des vues déguisées (ou inversement) ?
Bonjour,
je pense il n'y a pas vraiment de différence entre vues et requêtes HF.
Par contre, je pense que les requêtes HF, au moins en ce qui concerne HF
classic, sont des filtres déguisés sur les fichiers. Cette liaison
constante est aussi responsable des ralentissement de la requête lorsque
le fichier est modifié sur un autre poste. Les requêtes d'autres
produits ne montrent pas ce comportement, puisque les fichiers sont
envoyés du serveur au poste et traités localement.
Les lenteurs lorsqu'il y a beaucoup d'enregistrements dans le résultat
viennent du fait que le résultat est lu en mémoire, ligne par ligne.
Quand un tel résultat s'affiche de suite, c'est que la structure de la
requête et son entourage (fichiers et code) permettent que cela se passe
en arrière plan (on peut voir le compteur dans une table fait par le
RAD). Probablement, c'est aussi la raison principale pourquoi on ne peut
pas lancer directement une requête dans un thread.
Les lenteurs lors d'une requête COUNT proviennent peut-être du même fait
d'un filtre déguisé. Le résultat comprend tous les enregistrements
sélectionnés dans la requête, ensuite hExecuteRequete renvoi simplement
le total obtenu par une boucle POUR TOUS. Enfin, je ne vois nulle autre
explication pour le fait que le temps de traitement dépend du nombre
d'enregistrements traités ou présents dans le résultat. Malheureusement,
PC Soft n'ont jamais considéré important d'informer leurs client comment
fonctionne leur système de requêtes propriétaire afin de vraiment
pouvoir optimiser le code. On a préféré parler de problèmes inhérent au
code des développeurs ou au système d'exploitation.
J'ai justement fait un test entre les vues et les requêtes sur Hyperfile et le temps de réponse est pratiquement le même . J'ai un fichier d'environ 10 000 enregistrements et je les demande tous.
La première fois cela prend 15s et ensuite c'est 1s.
Les requêtes sur Hyperfile seraient des vues déguisées (ou inversement) ?
Bonjour,
je pense il n'y a pas vraiment de différence entre vues et requêtes HF. Par contre, je pense que les requêtes HF, au moins en ce qui concerne HF classic, sont des filtres déguisés sur les fichiers. Cette liaison constante est aussi responsable des ralentissement de la requête lorsque le fichier est modifié sur un autre poste. Les requêtes d'autres produits ne montrent pas ce comportement, puisque les fichiers sont envoyés du serveur au poste et traités localement.
Les lenteurs lorsqu'il y a beaucoup d'enregistrements dans le résultat viennent du fait que le résultat est lu en mémoire, ligne par ligne. Quand un tel résultat s'affiche de suite, c'est que la structure de la requête et son entourage (fichiers et code) permettent que cela se passe en arrière plan (on peut voir le compteur dans une table fait par le RAD). Probablement, c'est aussi la raison principale pourquoi on ne peut pas lancer directement une requête dans un thread.
Les lenteurs lors d'une requête COUNT proviennent peut-être du même fait d'un filtre déguisé. Le résultat comprend tous les enregistrements sélectionnés dans la requête, ensuite hExecuteRequete renvoi simplement le total obtenu par une boucle POUR TOUS. Enfin, je ne vois nulle autre explication pour le fait que le temps de traitement dépend du nombre d'enregistrements traités ou présents dans le résultat. Malheureusement, PC Soft n'ont jamais considéré important d'informer leurs client comment fonctionne leur système de requêtes propriétaire afin de vraiment pouvoir optimiser le code. On a préféré parler de problèmes inhérent au code des développeurs ou au système d'exploitation.
