J'ai la requête suivante qui attaque un fichier HF local au poste :
SELECT Utilisateurs.IDUTILISATEURS as IDUser, Utilisateurs.Nom_Uti + '
' + Utilisateurs.Pre_Uti AS NomUti
FROM Utilisateurs
WHERE Utilisateurs.Operateur = 0
AND Utilisateurs.IDClients = {pIDClient}
ORDER BY NomUti ASC
IDUTILISATEURS, Nom_Uti, Operateur & IDClients sont des clés doublons.
Le fichier compte 27 000 lignes
La requête prend 4s, celà me paraît énorme...Est-ce dû à la
concaténation ? Je remplis une liste déroulante avec...La requête ne
renvoie qu'une dizaine de résultats.
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
mat
JCM wrote: ...
SELECT Utilisateurs.IDUTILISATEURS as IDUser, Utilisateurs.Nom_Uti + ' ' + Utilisateurs.Pre_Uti AS NomUti FROM Utilisateurs WHERE Utilisateurs.Operateur = 0 AND Utilisateurs.IDClients = {pIDClient} ORDER BY NomUti ASC
...
La requête prend 4s, celà me paraît énorme...Est-ce dû à la concaténation ? Je remplis une liste déroulante avec...La requête ne renvoie qu'une dizaine de résultats.
...
Bonjour,
peut-être oui, en combinaison avec ORDER BY sur une rubrique faisant partie d'une chaîne concaténée. On peut essayer de mettre NomUti séparément dans le SELECT AS NomUti_2, pour le trie par "ORDER BY Nomuti_2".
Salutations Mat
JCM wrote:
...
SELECT Utilisateurs.IDUTILISATEURS as IDUser, Utilisateurs.Nom_Uti + '
' + Utilisateurs.Pre_Uti AS NomUti
FROM Utilisateurs
WHERE Utilisateurs.Operateur = 0
AND Utilisateurs.IDClients = {pIDClient}
ORDER BY NomUti ASC
...
La requête prend 4s, celà me paraît énorme...Est-ce dû à la
concaténation ? Je remplis une liste déroulante avec...La requête ne
renvoie qu'une dizaine de résultats.
...
Bonjour,
peut-être oui, en combinaison avec ORDER BY sur une rubrique faisant
partie d'une chaîne concaténée. On peut essayer de mettre NomUti
séparément dans le SELECT AS NomUti_2, pour le trie par "ORDER BY Nomuti_2".
SELECT Utilisateurs.IDUTILISATEURS as IDUser, Utilisateurs.Nom_Uti + ' ' + Utilisateurs.Pre_Uti AS NomUti FROM Utilisateurs WHERE Utilisateurs.Operateur = 0 AND Utilisateurs.IDClients = {pIDClient} ORDER BY NomUti ASC
...
La requête prend 4s, celà me paraît énorme...Est-ce dû à la concaténation ? Je remplis une liste déroulante avec...La requête ne renvoie qu'une dizaine de résultats.
...
Bonjour,
peut-être oui, en combinaison avec ORDER BY sur une rubrique faisant partie d'une chaîne concaténée. On peut essayer de mettre NomUti séparément dans le SELECT AS NomUti_2, pour le trie par "ORDER BY Nomuti_2".
Salutations Mat
patrice
"JCM" a écrit dans le message de news:45ffc5ad$0$19237$
Bonjour.
J'ai la requête suivante qui attaque un fichier HF local au poste :
SELECT Utilisateurs.IDUTILISATEURS as IDUser, Utilisateurs.Nom_Uti + ' ' + Utilisateurs.Pre_Uti AS NomUti FROM Utilisateurs WHERE Utilisateurs.Operateur = 0 AND Utilisateurs.IDClients = {pIDClient} ORDER BY NomUti ASC
IDUTILISATEURS, Nom_Uti, Operateur & IDClients sont des clés doublons. Le fichier compte 27 000 lignes
pour optimiser il faudrait que idclient,nomutil soit une clé composé pour que tri et selection s'opére sur une seule clé
La requête prend 4s, celà me paraît énorme...Est-ce dû à la concaténation ? Je remplis une liste déroulante avec...La requête ne renvoie qu'une dizaine de résultats.
penser aussi que en sql, c'est windev qui décide des clés à utiliser . Son critere sera probablement de favoriser les clés qui opérent la meilleur sélection en nombre d'enregistrement, et pour cela, il est indispensable que les stats soit calculées (cela n'est pas automatique)
"JCM" <dr_jcm@hotmail.com> a écrit dans le message de
news:45ffc5ad$0$19237$426a34cc@news.free.fr...
Bonjour.
J'ai la requête suivante qui attaque un fichier HF local au poste :
SELECT Utilisateurs.IDUTILISATEURS as IDUser, Utilisateurs.Nom_Uti + '
' + Utilisateurs.Pre_Uti AS NomUti
FROM Utilisateurs
WHERE Utilisateurs.Operateur = 0
AND Utilisateurs.IDClients = {pIDClient}
ORDER BY NomUti ASC
IDUTILISATEURS, Nom_Uti, Operateur & IDClients sont des clés doublons.
Le fichier compte 27 000 lignes
pour optimiser il faudrait que idclient,nomutil soit une clé composé pour
que tri et selection s'opére sur une seule clé
La requête prend 4s, celà me paraît énorme...Est-ce dû à la
concaténation ? Je remplis une liste déroulante avec...La requête ne
renvoie qu'une dizaine de résultats.
penser aussi que en sql, c'est windev qui décide des clés à utiliser . Son
critere sera probablement de favoriser les clés qui opérent la meilleur
sélection en nombre d'enregistrement, et pour cela, il est indispensable que
les stats soit calculées (cela n'est pas automatique)
"JCM" a écrit dans le message de news:45ffc5ad$0$19237$
Bonjour.
J'ai la requête suivante qui attaque un fichier HF local au poste :
SELECT Utilisateurs.IDUTILISATEURS as IDUser, Utilisateurs.Nom_Uti + ' ' + Utilisateurs.Pre_Uti AS NomUti FROM Utilisateurs WHERE Utilisateurs.Operateur = 0 AND Utilisateurs.IDClients = {pIDClient} ORDER BY NomUti ASC
IDUTILISATEURS, Nom_Uti, Operateur & IDClients sont des clés doublons. Le fichier compte 27 000 lignes
pour optimiser il faudrait que idclient,nomutil soit une clé composé pour que tri et selection s'opére sur une seule clé
La requête prend 4s, celà me paraît énorme...Est-ce dû à la concaténation ? Je remplis une liste déroulante avec...La requête ne renvoie qu'une dizaine de résultats.
penser aussi que en sql, c'est windev qui décide des clés à utiliser . Son critere sera probablement de favoriser les clés qui opérent la meilleur sélection en nombre d'enregistrement, et pour cela, il est indispensable que les stats soit calculées (cela n'est pas automatique)
mat
Puisque la question m'interesse, voici la réponse. L'éditeur SQL n'accepte pas de requête avec une rubrique dans ORDER BY qui ne figure pas dans le SELECT.
Le test suivant sur un fichier avec 46'000 enregistrements et plusieurs centaines dans la réponse s'exécute en moins d'une seconde. Et UserCode n'est pas une clé.
SELECT UserCode, Invoice + UserCode + Comments AS Code FROM Transaction WHERE IDProduct = 1430101 ORDER BY UserCode
Salutations Mat
Puisque la question m'interesse, voici la réponse.
L'éditeur SQL n'accepte pas de requête avec une rubrique dans ORDER BY
qui ne figure pas dans le SELECT.
Le test suivant sur un fichier avec 46'000 enregistrements et plusieurs
centaines dans la réponse s'exécute en moins d'une seconde. Et UserCode
n'est pas une clé.
SELECT UserCode, Invoice + UserCode + Comments AS Code FROM Transaction
WHERE IDProduct = 1430101
ORDER BY UserCode
Puisque la question m'interesse, voici la réponse. L'éditeur SQL n'accepte pas de requête avec une rubrique dans ORDER BY qui ne figure pas dans le SELECT.
Le test suivant sur un fichier avec 46'000 enregistrements et plusieurs centaines dans la réponse s'exécute en moins d'une seconde. Et UserCode n'est pas une clé.
SELECT UserCode, Invoice + UserCode + Comments AS Code FROM Transaction WHERE IDProduct = 1430101 ORDER BY UserCode
