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)
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 ...
J'ai crû que le DISTINCT me sauverait mais il supprime certains tuples qui ont pourtant leur place : un faux doublon (dont une rubrique "cachée" différerait) se retrouvera à moitié zappé. J'ai utilisé ça dans mon contournement, en faisant apparaître dans la requête la rubrique distinctive, seulement c'est de la prise de tête et effectivement ça ralentit tout lorsque la requête s'amuse à tout sélectionner 30 fois avant de virer tous les doublons :/
"dany" a écrit :
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 ...
J'ai crû que le DISTINCT me sauverait mais il supprime certains tuples qui
ont pourtant leur place : un faux doublon (dont une rubrique "cachée"
différerait) se retrouvera à moitié zappé.
J'ai utilisé ça dans mon contournement, en faisant apparaître dans la
requête la rubrique distinctive, seulement c'est de la prise de tête et
effectivement ça ralentit tout lorsque la requête s'amuse à tout
sélectionner 30 fois avant de virer tous les doublons :/
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 ...
J'ai crû que le DISTINCT me sauverait mais il supprime certains tuples qui ont pourtant leur place : un faux doublon (dont une rubrique "cachée" différerait) se retrouvera à moitié zappé. J'ai utilisé ça dans mon contournement, en faisant apparaître dans la requête la rubrique distinctive, seulement c'est de la prise de tête et effectivement ça ralentit tout lorsque la requête s'amuse à tout sélectionner 30 fois avant de virer tous les doublons :/
Joel
"Joel" a écrit :
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.
Le GROS point auquel je n'ai pas pensé est que je suis sur une analyse 5.5... A l'instant j'ai tenté de reproduire le bug sur un exemple Windev 7.5 avec analyse 7.5 et tout fonctionne normalement. Ce qui ne m'aide pas, je me vois pas passer toutes les données en 7.5 à ce jour. J'en déduis que trop de OU ou de IN sur une analyse 5.5 ça déconne et que ça restera comme ça.
Si quelqu'un travaille en WD7.5 sur HF 5.5 et veut bien confirmer, je lui en serai reconnaissant. Et si quelqu'un travaille en WD8 sur HF 5.5 et ne constate aucun problème, je suis sauvé.
"Joel" a écrit :
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.
Le GROS point auquel je n'ai pas pensé est que je suis sur une analyse
5.5... A l'instant j'ai tenté de reproduire le bug sur un exemple Windev 7.5
avec analyse 7.5 et tout fonctionne normalement. Ce qui ne m'aide pas, je me
vois pas passer toutes les données en 7.5 à ce jour.
J'en déduis que trop de OU ou de IN sur une analyse 5.5 ça déconne et que ça
restera comme ça.
Si quelqu'un travaille en WD7.5 sur HF 5.5 et veut bien confirmer, je lui en
serai reconnaissant. Et si quelqu'un travaille en WD8 sur HF 5.5 et ne
constate aucun problème, je suis sauvé.
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.
Le GROS point auquel je n'ai pas pensé est que je suis sur une analyse 5.5... A l'instant j'ai tenté de reproduire le bug sur un exemple Windev 7.5 avec analyse 7.5 et tout fonctionne normalement. Ce qui ne m'aide pas, je me vois pas passer toutes les données en 7.5 à ce jour. J'en déduis que trop de OU ou de IN sur une analyse 5.5 ça déconne et que ça restera comme ça.
Si quelqu'un travaille en WD7.5 sur HF 5.5 et veut bien confirmer, je lui en serai reconnaissant. Et si quelqu'un travaille en WD8 sur HF 5.5 et ne constate aucun problème, je suis sauvé.
Roumegou Eric
Support Japet.Info avait prétendu :
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.
Pur n'est pas le terme exact. C'est en SQL Oracle. (je crois que c'est le seul à l'utiliser ???) Et oracle en 9 c'est mis aussi à la syntaxe inner join et left join.
Mais je dois avouer que cette notation était extrèmement simple, surtout quand on devait générer par prog la requête; l'imbrication des join pouvant être beaucoup plus complexe.
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Support Japet.Info avait prétendu :
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.
Pur n'est pas le terme exact. C'est en SQL Oracle. (je crois que c'est
le seul à l'utiliser ???)
Et oracle en 9 c'est mis aussi à la syntaxe inner join et left join.
Mais je dois avouer que cette notation était extrèmement simple,
surtout quand on devait générer par prog la requête; l'imbrication des
join pouvant être beaucoup plus complexe.
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
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.
Pur n'est pas le terme exact. C'est en SQL Oracle. (je crois que c'est le seul à l'utiliser ???) Et oracle en 9 c'est mis aussi à la syntaxe inner join et left join.
Mais je dois avouer que cette notation était extrèmement simple, surtout quand on devait générer par prog la requête; l'imbrication des join pouvant être beaucoup plus complexe.
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Joel
"Joel" a écrit :
Si quelqu'un travaille en WD7.5 sur HF 5.5 et veut bien confirmer, je lui
en
serai reconnaissant. Et si quelqu'un travaille en WD8 sur HF 5.5 et ne constate aucun problème, je suis sauvé.
Bon, pour info, j'ai envoyé le morceau de projet à problème au STG. Une simple exécution sous Windev8 donne le bon résultat. o_O J'étais très bien en 7.5 mais ce détail va me faire passer à la 8, j'en peux plus du contournement.
"Joel" a écrit :
Si quelqu'un travaille en WD7.5 sur HF 5.5 et veut bien confirmer, je lui
en
serai reconnaissant. Et si quelqu'un travaille en WD8 sur HF 5.5 et ne
constate aucun problème, je suis sauvé.
Bon, pour info, j'ai envoyé le morceau de projet à problème au STG. Une
simple exécution sous Windev8 donne le bon résultat. o_O J'étais très bien
en 7.5 mais ce détail va me faire passer à la 8, j'en peux plus du
contournement.
Si quelqu'un travaille en WD7.5 sur HF 5.5 et veut bien confirmer, je lui
en
serai reconnaissant. Et si quelqu'un travaille en WD8 sur HF 5.5 et ne constate aucun problème, je suis sauvé.
Bon, pour info, j'ai envoyé le morceau de projet à problème au STG. Une simple exécution sous Windev8 donne le bon résultat. o_O J'étais très bien en 7.5 mais ce détail va me faire passer à la 8, j'en peux plus du contournement.
