A force de contourner j'ai creusé un sillon autour de mon poste de travail
:/
C'est très simple : des requêtes toutes bêtes. A partir d'un certain nombre
de conditions (3 ou 4) de type "est dans la liste", les tuples du résultat
se retrouvent en double, ou en triple, ou en autant d'exemplaires qu'il y a
d'éléments dans les listes utilisées par les conditions. Exemple tout simple
:
Je veux toutes les factures dont le fournisseur article est 01 ou 02 ou 03
(la liste est donc "01;02;03"), dont le rayon article est "01" ou "02",
entre le 1er janvier et le 31 décembre 2004. Hé bien les tuples vont se
retrouver en triple ! (et en quadruple si je demande un 4è fournisseur)
Quand je m'en suis rendu compte, Windev 7.5 n'était déjà plus supporté
(passage à la version 8).
Quelqu'un peut-il me dire s'il a constaté la même chose, ou encore si le bug
est toujours présent en 8 ? Je n'ai vu ça dans aucune de mes recherches sur
ce groupe de discussion.
(autre phénomène toujours selon le nombre de conditions : si je demande
comme liste de founisseurs "2", aucun résultat n'est trouvé, tandis que si
je demande "2;" (avec point-virgule), j'obtiens des enregistrements)
En général quand les enregistrements sont multipliés ainsi en fonction du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer cela.
Exemple :
WHERE FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la 2ème de l'égalité, fais un test).
"Joel" wrote in message news:<41753390$0$28607$...
Bonjour,
A force de contourner j'ai creusé un sillon autour de mon poste de travail :/
C'est très simple : des requêtes toutes bêtes. A partir d'un certain nombre de conditions (3 ou 4) de type "est dans la liste", les tuples du résultat se retrouvent en double, ou en triple, ou en autant d'exemplaires qu'il y a d'éléments dans les listes utilisées par les conditions. Exemple tout simple :
Je veux toutes les factures dont le fournisseur article est 01 ou 02 ou 03 (la liste est donc "01;02;03"), dont le rayon article est "01" ou "02", entre le 1er janvier et le 31 décembre 2004. Hé bien les tuples vont se retrouver en triple ! (et en quadruple si je demande un 4è fournisseur)
Quand je m'en suis rendu compte, Windev 7.5 n'était déjà plus supporté (passage à la version 8).
Quelqu'un peut-il me dire s'il a constaté la même chose, ou encore si le bug est toujours présent en 8 ? Je n'ai vu ça dans aucune de mes recherches sur ce groupe de discussion.
(autre phénomène toujours selon le nombre de conditions : si je demande comme liste de founisseurs "2", aucun résultat n'est trouvé, tandis que si je demande "2;" (avec point-virgule), j'obtiens des enregistrements)
Merci beaucoup et bon dév. Joël.
En général quand les enregistrements sont multipliés ainsi en fonction
du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il
n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer
cela.
Exemple :
WHERE
FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la
2ème de l'égalité, fais un test).
"Joel" <joel@nospam.fr> wrote in message news:<41753390$0$28607$8fcfb975@news.wanadoo.fr>...
Bonjour,
A force de contourner j'ai creusé un sillon autour de mon poste de travail
:/
C'est très simple : des requêtes toutes bêtes. A partir d'un certain nombre
de conditions (3 ou 4) de type "est dans la liste", les tuples du résultat
se retrouvent en double, ou en triple, ou en autant d'exemplaires qu'il y a
d'éléments dans les listes utilisées par les conditions. Exemple tout simple
:
Je veux toutes les factures dont le fournisseur article est 01 ou 02 ou 03
(la liste est donc "01;02;03"), dont le rayon article est "01" ou "02",
entre le 1er janvier et le 31 décembre 2004. Hé bien les tuples vont se
retrouver en triple ! (et en quadruple si je demande un 4è fournisseur)
Quand je m'en suis rendu compte, Windev 7.5 n'était déjà plus supporté
(passage à la version 8).
Quelqu'un peut-il me dire s'il a constaté la même chose, ou encore si le bug
est toujours présent en 8 ? Je n'ai vu ça dans aucune de mes recherches sur
ce groupe de discussion.
(autre phénomène toujours selon le nombre de conditions : si je demande
comme liste de founisseurs "2", aucun résultat n'est trouvé, tandis que si
je demande "2;" (avec point-virgule), j'obtiens des enregistrements)
En général quand les enregistrements sont multipliés ainsi en fonction du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer cela.
Exemple :
WHERE FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la 2ème de l'égalité, fais un test).
"Joel" wrote in message news:<41753390$0$28607$...
Bonjour,
A force de contourner j'ai creusé un sillon autour de mon poste de travail :/
C'est très simple : des requêtes toutes bêtes. A partir d'un certain nombre de conditions (3 ou 4) de type "est dans la liste", les tuples du résultat se retrouvent en double, ou en triple, ou en autant d'exemplaires qu'il y a d'éléments dans les listes utilisées par les conditions. Exemple tout simple :
Je veux toutes les factures dont le fournisseur article est 01 ou 02 ou 03 (la liste est donc "01;02;03"), dont le rayon article est "01" ou "02", entre le 1er janvier et le 31 décembre 2004. Hé bien les tuples vont se retrouver en triple ! (et en quadruple si je demande un 4è fournisseur)
Quand je m'en suis rendu compte, Windev 7.5 n'était déjà plus supporté (passage à la version 8).
Quelqu'un peut-il me dire s'il a constaté la même chose, ou encore si le bug est toujours présent en 8 ? Je n'ai vu ça dans aucune de mes recherches sur ce groupe de discussion.
(autre phénomène toujours selon le nombre de conditions : si je demande comme liste de founisseurs "2", aucun résultat n'est trouvé, tandis que si je demande "2;" (avec point-virgule), j'obtiens des enregistrements)
Merci beaucoup et bon dév. Joël.
Joel
Support Japet.Info a écrit :
En général quand les enregistrements sont multipliés ainsi en fonction du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer cela.
Exemple :
WHERE FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la 2ème de l'égalité, fais un test).
Merci... Le détail c'est qu'il n'y a aucune jointure dans mes requêtes, tout se passe dans une seule table. Elles sont vraiment tout ce qu'il y a de + simple :
WHERE facture.codefournisseur IN ('01','02','03')
C'est d'autant plus désolant. Voici une illustration du phénomène, avec la requête, ses paramètres et son résultat :
En général quand les enregistrements sont multipliés ainsi en fonction
du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il
n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer
cela.
Exemple :
WHERE
FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la
2ème de l'égalité, fais un test).
Merci... Le détail c'est qu'il n'y a aucune jointure dans mes requêtes, tout
se passe dans une seule table. Elles sont vraiment tout ce qu'il y a de +
simple :
WHERE
facture.codefournisseur IN ('01','02','03')
C'est d'autant plus désolant. Voici une illustration du phénomène, avec la
requête, ses paramètres et son résultat :
En général quand les enregistrements sont multipliés ainsi en fonction du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer cela.
Exemple :
WHERE FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la 2ème de l'égalité, fais un test).
Merci... Le détail c'est qu'il n'y a aucune jointure dans mes requêtes, tout se passe dans une seule table. Elles sont vraiment tout ce qu'il y a de + simple :
WHERE facture.codefournisseur IN ('01','02','03')
C'est d'autant plus désolant. Voici une illustration du phénomène, avec la requête, ses paramètres et son résultat :
En général quand les enregistrements sont multipliés ainsi en fonction du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer cela.
non en sql Oracle !
en sql pur c'est des outer join...
Exemple :
WHERE FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la 2ème de l'égalité, fais un test).
"Joel" wrote in message news:<41753390$0$28607$...
Bonjour,
A force de contourner j'ai creusé un sillon autour de mon poste de travail :/
C'est très simple : des requêtes toutes bêtes. A partir d'un certain nombre de conditions (3 ou 4) de type "est dans la liste", les tuples du résultat se retrouvent en double, ou en triple, ou en autant d'exemplaires qu'il y a d'éléments dans les listes utilisées par les conditions. Exemple tout simple
Je veux toutes les factures dont le fournisseur article est 01 ou 02 ou 03 (la liste est donc "01;02;03"), dont le rayon article est "01" ou "02", entre le 1er janvier et le 31 décembre 2004. Hé bien les tuples vont se retrouver en triple ! (et en quadruple si je demande un 4è fournisseur)
Quand je m'en suis rendu compte, Windev 7.5 n'était déjà plus supporté (passage à la version 8).
Quelqu'un peut-il me dire s'il a constaté la même chose, ou encore si le bug est toujours présent en 8 ? Je n'ai vu ça dans aucune de mes recherches sur ce groupe de discussion.
(autre phénomène toujours selon le nombre de conditions : si je demande comme liste de founisseurs "2", aucun résultat n'est trouvé, tandis que si je demande "2;" (avec point-virgule), j'obtiens des enregistrements)
Merci beaucoup et bon dév. Joël.
Support Japet.Info wrote:
En général quand les enregistrements sont multipliés ainsi en fonction
du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il
n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer
cela.
non en sql Oracle !
en sql pur c'est des outer join...
Exemple :
WHERE
FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la
2ème de l'égalité, fais un test).
"Joel" <joel@nospam.fr> wrote in message
news:<41753390$0$28607$8fcfb975@news.wanadoo.fr>...
Bonjour,
A force de contourner j'ai creusé un sillon autour de mon poste de
travail :/
C'est très simple : des requêtes toutes bêtes. A partir d'un certain
nombre de conditions (3 ou 4) de type "est dans la liste", les
tuples du résultat se retrouvent en double, ou en triple, ou en
autant d'exemplaires qu'il y a d'éléments dans les listes utilisées
par les conditions. Exemple tout simple
Je veux toutes les factures dont le fournisseur article est 01 ou 02
ou 03 (la liste est donc "01;02;03"), dont le rayon article est "01"
ou "02", entre le 1er janvier et le 31 décembre 2004. Hé bien les
tuples vont se retrouver en triple ! (et en quadruple si je demande
un 4è fournisseur)
Quand je m'en suis rendu compte, Windev 7.5 n'était déjà plus
supporté (passage à la version 8).
Quelqu'un peut-il me dire s'il a constaté la même chose, ou encore
si le bug est toujours présent en 8 ? Je n'ai vu ça dans aucune de
mes recherches sur ce groupe de discussion.
(autre phénomène toujours selon le nombre de conditions : si je
demande comme liste de founisseurs "2", aucun résultat n'est trouvé,
tandis que si je demande "2;" (avec point-virgule), j'obtiens des
enregistrements)
En général quand les enregistrements sont multipliés ainsi en fonction du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer cela.
non en sql Oracle !
en sql pur c'est des outer join...
Exemple :
WHERE FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la 2ème de l'égalité, fais un test).
"Joel" wrote in message news:<41753390$0$28607$...
Bonjour,
A force de contourner j'ai creusé un sillon autour de mon poste de travail :/
C'est très simple : des requêtes toutes bêtes. A partir d'un certain nombre de conditions (3 ou 4) de type "est dans la liste", les tuples du résultat se retrouvent en double, ou en triple, ou en autant d'exemplaires qu'il y a d'éléments dans les listes utilisées par les conditions. Exemple tout simple
Je veux toutes les factures dont le fournisseur article est 01 ou 02 ou 03 (la liste est donc "01;02;03"), dont le rayon article est "01" ou "02", entre le 1er janvier et le 31 décembre 2004. Hé bien les tuples vont se retrouver en triple ! (et en quadruple si je demande un 4è fournisseur)
Quand je m'en suis rendu compte, Windev 7.5 n'était déjà plus supporté (passage à la version 8).
Quelqu'un peut-il me dire s'il a constaté la même chose, ou encore si le bug est toujours présent en 8 ? Je n'ai vu ça dans aucune de mes recherches sur ce groupe de discussion.
(autre phénomène toujours selon le nombre de conditions : si je demande comme liste de founisseurs "2", aucun résultat n'est trouvé, tandis que si je demande "2;" (avec point-virgule), j'obtiens des enregistrements)
Merci beaucoup et bon dév. Joël.
Manu
> Merci... Le détail c'est qu'il n'y a aucune jointure dans mes requêtes, tout se passe dans une seule table. Elles sont vraiment tout ce qu'il y a de + simple :
Que donne un affichage complet de la ligne (select *) car tu peux avoir des données triplées sur 3 enreg et le reste change... du genre une ligne par taux de tva...
> Merci... Le détail c'est qu'il n'y a aucune jointure dans mes
requêtes, tout se passe dans une seule table. Elles sont vraiment
tout ce qu'il y a de + simple :
Que donne un affichage complet de la ligne (select *) car tu peux avoir des
données triplées sur 3 enreg et le reste change... du genre une ligne par
taux de tva...
> Merci... Le détail c'est qu'il n'y a aucune jointure dans mes requêtes, tout se passe dans une seule table. Elles sont vraiment tout ce qu'il y a de + simple :
Que donne un affichage complet de la ligne (select *) car tu peux avoir des données triplées sur 3 enreg et le reste change... du genre une ligne par taux de tva...
dany
"Joel" a écrit dans le message de news: 41761fbd$0$28601$
Support Japet.Info a écrit :
En général quand les enregistrements sont multipliés ainsi en fonction du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer cela.
Exemple :
WHERE FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la 2ème de l'égalité, fais un test).
Merci... Le détail c'est qu'il n'y a aucune jointure dans mes requêtes, tout se passe dans une seule table. Elles sont vraiment tout ce qu'il y a de + simple :
WHERE facture.codefournisseur IN ('01','02','03')
C'est d'autant plus désolant. Voici une illustration du phénomène, avec la requête, ses paramètres et son résultat :
as-tu essayé where facture.codefournisseur='01' or facture.codefournisseur='02' or facture.codefournisseur='03'
est-ce que si tu mets facture.codefournisseur IN ('01','02','03','04') ca te les sort en quadruple ?
"Joel" <joel@nospam.fr> a écrit dans le message de news:
41761fbd$0$28601$8fcfb975@news.wanadoo.fr...
Support Japet.Info a écrit :
En général quand les enregistrements sont multipliés ainsi en fonction
du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il
n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer
cela.
Exemple :
WHERE
FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la
2ème de l'égalité, fais un test).
Merci... Le détail c'est qu'il n'y a aucune jointure dans mes requêtes,
tout
se passe dans une seule table. Elles sont vraiment tout ce qu'il y a de +
simple :
WHERE
facture.codefournisseur IN ('01','02','03')
C'est d'autant plus désolant. Voici une illustration du phénomène, avec la
requête, ses paramètres et son résultat :
"Joel" a écrit dans le message de news: 41761fbd$0$28601$
Support Japet.Info a écrit :
En général quand les enregistrements sont multipliés ainsi en fonction du nombre d'élément, c'est qu'il y a un problème sur une jointure.
Il y a certainement un des codes fournisseurs demandés pour lequel il n'y a pas de facture avec les autres critères.
En SQL 'pur', on ajoute (+) à côté du nom de la colonne pour gérer cela.
Exemple :
WHERE FOURNISSEUR.CODE(+) = FACTURE.CODEFOURNISSEUR
(ceci dit, je ne sais plus si le + se met sur la 1ère partie ou la 2ème de l'égalité, fais un test).
Merci... Le détail c'est qu'il n'y a aucune jointure dans mes requêtes, tout se passe dans une seule table. Elles sont vraiment tout ce qu'il y a de + simple :
WHERE facture.codefournisseur IN ('01','02','03')
C'est d'autant plus désolant. Voici une illustration du phénomène, avec la requête, ses paramètres et son résultat :
as-tu essayé where facture.codefournisseur='01' or facture.codefournisseur='02' or facture.codefournisseur='03'
est-ce que si tu mets facture.codefournisseur IN ('01','02','03','04') ca te les sort en quadruple ?
Joel
"dany" a écrit :
as-tu essayé where facture.codefournisseur='01' or facture.codefournisseur='02' or facture.codefournisseur='03'
Oui, avant de me lancer dans les IN j'ai tenté les OR, le phénomène était le même. Précision : ce n'est pas une requête saisie mais une requête créée sous l'éditeur. Mais saisie directement en SQL, il se passe la même chose.
est-ce que si tu mets facture.codefournisseur IN ('01','02','03','04') ca te les sort en quadruple ?
Oui, et quand la liste contient 30 fournisseurs, la requête rame et m'affiche tout en 30 exemplaires : l'enfer.
"dany" a écrit :
as-tu essayé
where facture.codefournisseur='01'
or facture.codefournisseur='02'
or facture.codefournisseur='03'
Oui, avant de me lancer dans les IN j'ai tenté les OR, le phénomène était le
même. Précision : ce n'est pas une requête saisie mais une requête créée
sous l'éditeur. Mais saisie directement en SQL, il se passe la même chose.
est-ce que si tu mets facture.codefournisseur IN ('01','02','03','04') ca
te les sort en quadruple ?
Oui, et quand la liste contient 30 fournisseurs, la requête rame et
m'affiche tout en 30 exemplaires : l'enfer.
as-tu essayé where facture.codefournisseur='01' or facture.codefournisseur='02' or facture.codefournisseur='03'
Oui, avant de me lancer dans les IN j'ai tenté les OR, le phénomène était le même. Précision : ce n'est pas une requête saisie mais une requête créée sous l'éditeur. Mais saisie directement en SQL, il se passe la même chose.
est-ce que si tu mets facture.codefournisseur IN ('01','02','03','04') ca te les sort en quadruple ?
Oui, et quand la liste contient 30 fournisseurs, la requête rame et m'affiche tout en 30 exemplaires : l'enfer.
Joel
"Manu" a écrit :
Que donne un affichage complet de la ligne (select *) car tu peux avoir
des
données triplées sur 3 enreg et le reste change... du genre une ligne par taux de tva...
Je ne peux pas demander "*" sous l'éditeur de requêtes, mais j'ai bien vérifié sous WDMap avec les mêmes conditions et seuls 49 enregistrements correspondent (et non pas 147 ou autant de fois 49 qu'il y a d'éléments dans la liste "fournisseur". J'y avais pensé ;)
Une requête saisie en SQL avec ou sans "*" donne la même chose.
Déroutant.
"Manu" a écrit :
Que donne un affichage complet de la ligne (select *) car tu peux avoir
des
données triplées sur 3 enreg et le reste change... du genre une ligne par
taux de tva...
Je ne peux pas demander "*" sous l'éditeur de requêtes, mais j'ai bien
vérifié sous WDMap avec les mêmes conditions et seuls 49 enregistrements
correspondent (et non pas 147 ou autant de fois 49 qu'il y a d'éléments dans
la liste "fournisseur". J'y avais pensé ;)
Une requête saisie en SQL avec ou sans "*" donne la même chose.
Que donne un affichage complet de la ligne (select *) car tu peux avoir
des
données triplées sur 3 enreg et le reste change... du genre une ligne par taux de tva...
Je ne peux pas demander "*" sous l'éditeur de requêtes, mais j'ai bien vérifié sous WDMap avec les mêmes conditions et seuls 49 enregistrements correspondent (et non pas 147 ou autant de fois 49 qu'il y a d'éléments dans la liste "fournisseur". J'y avais pensé ;)
Une requête saisie en SQL avec ou sans "*" donne la même chose.
Déroutant.
dany
"Joel" a écrit dans le message de news: 41762cad$0$28811$
"dany" a écrit :
as-tu essayé where facture.codefournisseur='01' or facture.codefournisseur='02' or facture.codefournisseur='03'
Oui, avant de me lancer dans les IN j'ai tenté les OR, le phénomène était le même. Précision : ce n'est pas une requête saisie mais une requête créée sous l'éditeur. Mais saisie directement en SQL, il se passe la même chose.
est-ce que si tu mets facture.codefournisseur IN ('01','02','03','04') ca te les sort en quadruple ?
Oui, et quand la liste contient 30 fournisseurs, la requête rame et m'affiche tout en 30 exemplaires : l'enfer.
avec un select distinct ? c'est sencé supprimer les doublons, j'ignore si les performances seront au rendez-vous. C'est effectivement très étrange ...
"Joel" <joel@nospam.fr> a écrit dans le message de news:
41762cad$0$28811$8fcfb975@news.wanadoo.fr...
"dany" a écrit :
as-tu essayé
where facture.codefournisseur='01'
or facture.codefournisseur='02'
or facture.codefournisseur='03'
Oui, avant de me lancer dans les IN j'ai tenté les OR, le phénomène était
le
même. Précision : ce n'est pas une requête saisie mais une requête créée
sous l'éditeur. Mais saisie directement en SQL, il se passe la même chose.
est-ce que si tu mets facture.codefournisseur IN ('01','02','03','04')
ca
te les sort en quadruple ?
Oui, et quand la liste contient 30 fournisseurs, la requête rame et
m'affiche tout en 30 exemplaires : l'enfer.
avec un select distinct ?
c'est sencé supprimer les doublons, j'ignore si les performances seront au
rendez-vous.
C'est effectivement très étrange ...
"Joel" a écrit dans le message de news: 41762cad$0$28811$
"dany" a écrit :
as-tu essayé where facture.codefournisseur='01' or facture.codefournisseur='02' or facture.codefournisseur='03'
Oui, avant de me lancer dans les IN j'ai tenté les OR, le phénomène était le même. Précision : ce n'est pas une requête saisie mais une requête créée sous l'éditeur. Mais saisie directement en SQL, il se passe la même chose.
est-ce que si tu mets facture.codefournisseur IN ('01','02','03','04') ca te les sort en quadruple ?
Oui, et quand la liste contient 30 fournisseurs, la requête rame et m'affiche tout en 30 exemplaires : l'enfer.
avec un select distinct ? c'est sencé supprimer les doublons, j'ignore si les performances seront au rendez-vous. C'est effectivement très étrange ...
Manu
Joel wrote:
"Manu" a écrit :
Que donne un affichage complet de la ligne (select *) car tu peux avoir des données triplées sur 3 enreg et le reste change... du genre une ligne par taux de tva...
Je ne peux pas demander "*" sous l'éditeur de requêtes, mais j'ai bien vérifié sous WDMap avec les mêmes conditions et seuls 49 enregistrements correspondent (et non pas 147 ou autant de fois 49 qu'il y a d'éléments dans la liste "fournisseur". J'y avais pensé ;)
Une requête saisie en SQL avec ou sans "*" donne la même chose.
quel est le code SQL généré par la requete stp ?
Déroutant.
attendons de voir le code SQL.
Joel wrote:
"Manu" a écrit :
Que donne un affichage complet de la ligne (select *) car tu peux
avoir des données triplées sur 3 enreg et le reste change... du
genre une ligne par taux de tva...
Je ne peux pas demander "*" sous l'éditeur de requêtes, mais j'ai bien
vérifié sous WDMap avec les mêmes conditions et seuls 49
enregistrements correspondent (et non pas 147 ou autant de fois 49
qu'il y a d'éléments dans la liste "fournisseur". J'y avais pensé ;)
Une requête saisie en SQL avec ou sans "*" donne la même chose.
Que donne un affichage complet de la ligne (select *) car tu peux avoir des données triplées sur 3 enreg et le reste change... du genre une ligne par taux de tva...
Je ne peux pas demander "*" sous l'éditeur de requêtes, mais j'ai bien vérifié sous WDMap avec les mêmes conditions et seuls 49 enregistrements correspondent (et non pas 147 ou autant de fois 49 qu'il y a d'éléments dans la liste "fournisseur". J'y avais pensé ;)
Une requête saisie en SQL avec ou sans "*" donne la même chose.
quel est le code SQL généré par la requete stp ?
Déroutant.
attendons de voir le code SQL.
Joel
"Manu" a écrit :
quel est le code SQL généré par la requete stp ?
Sous l'éditeur ?
SELECT FP_ART01.ART_DAT01 AS ART_DAT01, FP_ART01.fou_cod01 AS fou_cod01, FP_ART01.RAY_COD01 AS RAY_COD01 FROM FP_ART01 WHERE FP_ART01.ART_DAT01 BETWEEN Param1 AND Param2 AND FP_ART01.fou_cod01 IN (Param3) AND FP_ART01.RAY_COD01 IN (Param4)
Et si je saisis la requête suivante :
select * from fp_art01 where fp_art01.art_dat01 between {param1} and {param2} and fp_art01.fou_cod01 in ({param3}) and fp_art01.ray_cod01 in ({param4});
On obtient la même chose.
attendons de voir le code SQL.
Il n'a pourtant rien de particulier je crois.
"Manu" a écrit :
quel est le code SQL généré par la requete stp ?
Sous l'éditeur ?
SELECT FP_ART01.ART_DAT01 AS ART_DAT01,
FP_ART01.fou_cod01 AS fou_cod01,
FP_ART01.RAY_COD01 AS RAY_COD01
FROM FP_ART01
WHERE FP_ART01.ART_DAT01 BETWEEN Param1 AND Param2
AND FP_ART01.fou_cod01 IN (Param3)
AND FP_ART01.RAY_COD01 IN (Param4)
Et si je saisis la requête suivante :
select * from fp_art01
where fp_art01.art_dat01 between {param1} and {param2}
and fp_art01.fou_cod01 in ({param3})
and fp_art01.ray_cod01 in ({param4});
SELECT FP_ART01.ART_DAT01 AS ART_DAT01, FP_ART01.fou_cod01 AS fou_cod01, FP_ART01.RAY_COD01 AS RAY_COD01 FROM FP_ART01 WHERE FP_ART01.ART_DAT01 BETWEEN Param1 AND Param2 AND FP_ART01.fou_cod01 IN (Param3) AND FP_ART01.RAY_COD01 IN (Param4)
Et si je saisis la requête suivante :
select * from fp_art01 where fp_art01.art_dat01 between {param1} and {param2} and fp_art01.fou_cod01 in ({param3}) and fp_art01.ray_cod01 in ({param4});
