Bonjour à tous
Je viens de migrer une grosse appli de WD8 en 9 dernière version (34j)
Plusieurs de mes requètes ne fonctionnent plus: à l'exécution, j'ai le
message d'attente et les requetes ne renvoient pas de résultats !!!!!
Voici une des requetes qui ne fonctionne plus, alors qu'elle fonctionnait
parfaitement avec WD8:
SELECT C.IDCLICOT, C.TYPE, C.NUMERO, C.IDUTILISAT, C.NUMSOC, C.RAISON,
C.NUMDEVGEN, C.NUMDEVART, C.NUMDEVPRE,
C.ADRESSE1 as ClicotAdresse1, C.ADRESSE2 as ClicotAdresse2, C.CODEPOST as
ClicotCodePost, C.VILLE as ClicotVille, C.PAYS as ClicotPays,
C.DATE, C.DATEVALID, C.OBSERV1, C.OBSERV2, C.REFCLI, C.NUMTVA, C.CONDVEND,
rtrim(C.ABRLANGUE) as AbrLangue, C.REMISE as RemGen,
S.ADRESSE1 as SocieteAdresse1, S.ADRESSE2 as SocieteAdresse2, S.VILLE as
SocieteVille, S.CODEPOST as SocieteCodePost,
S.PAYS as SocietePays, S.TELEPHONE as SocieteTelephone, S.FAX as SocieteFax,
S.FICLOGO, S.EMAIL,
C1.NUMERO as CliCotLGNumero, C1.NUMENS, C1.NUMGRP, C1.NUMLIGNE,
C1.DESIGNATION as CliCotLGDesignation, C1.ETAT, C1.QTE, C1.PRIX, C1.REMISE,
C1.DELAIJ, C1.NUMTVA, C1.TAUXTVA, C1.NUMDEV,
C2.RAISON as ConstrucRaison,
C4.CIVILITE, rtrim(C4.PRENOM) as CliCorrPrenom, rtrim(C4.NOM) as CliCorrNom,
C4.TELEPHONE as CliCorrTeleph, C4.FAX as CliCorrFax,
G.LIBGROUPE, T.RAISON, R.DESIGNATION as ReglementDesignation,
A.IDARTICLE, A.DESIGNATION as ArticleDesignation, A.REFCONST, A.NUMCAT
from CLICOT C, SOCIETE S, DEVISE D, CLICOTLG C1, GROUPE G,
CLICOTLG left outer join TRANSPOR T on C1.IDFOURNISS = T.IDTRANSPOR,
CLICOTLG left outer join ARTICLE A on C1.IDARTICLE = A.IDARTICLE,
ARTICLE left outer join CONSTRUC C2 on (C2.ABRCONST = A.ABRCONST),
CLICOT left outer join CLICORR C4 on C.IDCLICORR = C4.IDCLICORR,
CLICOT left outer join UTILISAT U on C.IDUTILISAT = U.IDUTILISAT,
CLICOT left outer join REGLEMEN R on C.NUMREGL = R.NUMREGL
where (C.IDCLICOT = {pC0CleUnik})
and (C.NUMSOC = S.NUMSOC)
and (C1.IDCLICOT = C.IDCLICOT)
and (C1.NUMDEV = D.NUMDEV)
and (U.IDGROUPE = G.IDGROUPE)
order by NUMENS, NUMGRP, NUMLIGNE
Est-ce que le problème ne peut pas venir des OUTER JOIN multiples (suur
CLICOTLG ici dans l'exemple) ?
Quelqu'un connait-il une solution rapide car j'ai suivi la pub PCSoft
"recompilez et ça marche" et j'ai mis en exploitation l'appli (utilisateurs
bloqués) ?
Je voudrais bien sûr éviter de tester toutes les requetes du projet une à
une !!!
C'est pas nouveau ; en tout cas en passant par une correction HyperFile, il met meme un warning au deuxieme join (outer -right ou left- ou inner) Mais moi, je l'utilise en passant par SQLExec() et pas de pb (Edit apres relecture : Ah mais je suis sur une base non HyperFile, c'est pour ca) . As tu essayé de remplacer tes jointures propres par un produit cartésien avec condition dans le where ?
Non j'ai pas essayé, suis pas au fait des finesses du SQL !!! produit cartésien = UNION ?
Non, produit cartésien de deux tables : select * from tabA, tabB pour avoir le meme résultat qu un inner join, tu ajoutes : where tabA.idA = tabB.idA. Mais en y regardant de plus pres, c'est déjà fait. Le seul probleme vient donc des jointures externes ; ce qui est plus chiant à faire. Parfois (pas toujours, suivant le SGDB et je connais pas comment HF réagit), ca peut marcher en faisant ca : where tabA.idA = tabB.idA or tabB.idA is null
Sinon, tu peux passer par une table tempo, ce qui est loin d etre simple et rapide si tu as beaucoup de requetes à traiter.
> [CUT]
Ben pourtant ca marche en version 8 -315p
C'est tout de meme dingue ! ca remarchera peut etre en 10 alors ;-)
-- Manu
I.G.LOG a écrit :
C'est pas nouveau ; en tout cas en passant par une correction HyperFile,
il met meme un warning au deuxieme join (outer -right ou left- ou inner)
Mais moi, je l'utilise en passant par SQLExec() et pas de pb (Edit apres
relecture : Ah mais je suis sur une base non HyperFile, c'est pour ca) .
As tu essayé de remplacer tes jointures propres par un produit cartésien
avec condition dans le where ?
Non j'ai pas essayé, suis pas au fait des finesses du SQL !!!
produit cartésien = UNION ?
Non, produit cartésien de deux tables : select * from tabA, tabB
pour avoir le meme résultat qu un inner join, tu ajoutes : where
tabA.idA = tabB.idA. Mais en y regardant de plus pres, c'est déjà fait.
Le seul probleme vient donc des jointures externes ; ce qui est plus
chiant à faire. Parfois (pas toujours, suivant le SGDB et je connais pas
comment HF réagit), ca peut marcher en faisant ca :
where tabA.idA = tabB.idA or tabB.idA is null
Sinon, tu peux passer par une table tempo, ce qui est loin d etre simple
et rapide si tu as beaucoup de requetes à traiter.
> [CUT]
Ben pourtant ca marche en version 8 -315p
C'est tout de meme dingue !
ca remarchera peut etre en 10 alors ;-)
C'est pas nouveau ; en tout cas en passant par une correction HyperFile, il met meme un warning au deuxieme join (outer -right ou left- ou inner) Mais moi, je l'utilise en passant par SQLExec() et pas de pb (Edit apres relecture : Ah mais je suis sur une base non HyperFile, c'est pour ca) . As tu essayé de remplacer tes jointures propres par un produit cartésien avec condition dans le where ?
Non j'ai pas essayé, suis pas au fait des finesses du SQL !!! produit cartésien = UNION ?
Non, produit cartésien de deux tables : select * from tabA, tabB pour avoir le meme résultat qu un inner join, tu ajoutes : where tabA.idA = tabB.idA. Mais en y regardant de plus pres, c'est déjà fait. Le seul probleme vient donc des jointures externes ; ce qui est plus chiant à faire. Parfois (pas toujours, suivant le SGDB et je connais pas comment HF réagit), ca peut marcher en faisant ca : where tabA.idA = tabB.idA or tabB.idA is null
Sinon, tu peux passer par une table tempo, ce qui est loin d etre simple et rapide si tu as beaucoup de requetes à traiter.
> [CUT]
Ben pourtant ca marche en version 8 -315p
C'est tout de meme dingue ! ca remarchera peut etre en 10 alors ;-)
