ORA-01799: une colonne ne peut pas être extérieur-joint à une sous-requête

Voici ma requête

SELECT 
    COUNT(C.SETID)
FROM 
    MYCUSTOMER C
    LEFT OUTER JOIN MYCUSTOPTION CO 
    ON 
        (C.SETID = CO.SETID 
            AND C.CUST_ID = CO.CUST_ID 
            AND CO.effdt = ( 
                SELECT MAX(COI.EFFDT) 
                FROM MYCUSTOPTION COI 
                WHERE 
                    COI.SETID = CO.SETID 
                                    AND COI.CUST_ID = CO.CUST_ID 
                                    AND COI.EFFDT <=SYSDATE    
                )
    )

et voici le message d'erreur que je reçois..

Ce que je fais mal???

Campus Des Solutions? Yukk!

OriginalL'auteur dotnet-practitioner | 2013-01-28

oracle oracle-sqldeveloper

vous pouvez réécrire qu'en appuyant sur la sous-requête, de sorte que ce n'est pas externe joint:

select Count(C.setid)
  from mycustomer C
       left outer join (select *
                          from mycustoption co
                         where co.effdt <= (select Max(COI.effdt)
                                              from mycustoption COI
                                             where COI.setid = co.setid
                                               and COI.cust_id = co.cust_id
                                               and COI.effdt <= sysdate)) co
                    on ( C.setid = CO.setid
                         and C.cust_id = CO.cust_id )

J'ai oublié le " co "à la fin de l'intérieur de l'instruction select (après la sysdate), de le confondre avec le" co " au début de l'intérieur, de l'instruction select. Dans ma requête, j'ai fait ceux qui sont différents, pour éviter que la confusion. Mais, c'est exactement ce que je cherchais.

OriginalL'auteur DazzaL

2

Bien, Oracle, apparemment, ne prend pas en charge l'utilisation d'une sous-requête à l'intérieur de la condition de jointure pour une jointure externe. Si vous avez besoin de se débarrasser de la sous-requête.

La question est, pourquoi est-il là? Vous avez "<=" les conditions dans les deux endroits, de sorte que le prédicat dit essentiellement: "tous les enregistrements dont la date d'entrée en vigueur, au plus tard le dernier date d'entrée en vigueur, au plus tard maintenant". Si c'est ce que vous voulez vraiment, vous pouvez simplifier à "tous les enregistrements dont la date d'entrée en vigueur est pas plus tard que maintenant", c'est à dire:
```
ON 
    (C.SETID = CO.SETID 
        AND C.CUST_ID = CO.CUST_ID 
        AND CO.effdt <= SYSDATE    
)
```
Voila, pas de sous-requête.

Mais est-ce vraiment ce que vous souhaitez ou avez-vous dire que la première "<=" simplement "=" -- c'est à dire trouver le record de la plus récente date d'entrée en vigueur avant aujourd'hui? Si c'est ce que vous voulez vraiment, il sera plus complexe de réécriture.

nous avons besoin de ramasser de l'enregistrement qui est plus récent dans MYCUSTOPTION pour que cust_id...
mise à jour de la requête et a <= dans la première clause externe

OriginalL'auteur Dave Costa

Votre question a déjà été posée, mais quelqu'un pourrait avoir un cas un peu différent où ils ont besoin pour obtenir les dernières EFFDT basé sur une colonne, au lieu d'une date fixe. Pour ces cas, je n'en ai trouvé un IMPARFAIT de l'option, et un LAID solution...

Imparfaite option:

SELECT ...
FROM MYTABLE N, CUST_OPT C
WHERE  etc...
AND C.SETID           (+) = N.SETID
AND C.CUST_ID         (+) = N.CUST_ID
AND NVL(C.EFFDT,TO_DATE('01011900','DDMMYYYY')) = NVL((SELECT MAX(EFFDT)
                                                       FROM CUST_OPT SC
                                                       WHERE SC.SETID = C.SETID
                                                       AND   SC.CUST_ID = C.CUST_ID
                                                       AND   SC.EFFDT <= N.ISSUE_DT)
                                                       ,TO_DATE('01011900','DDMMYYYY'))

C'est une mauvaise option, car si le CUST_OPT table a des dates futures, mais pas de courant (<=N. ISSUE_DT) les dates, la jointure externe ne fonctionne pas et aucune ligne ne sera retourné. En général, PeopleSoft termes (oui, j'ai vu votre SETID+EFFDT là! ;-D), ce ne serait pas arriver très souvent que les gens ont tendance à créer un 01/01/1900 EFFDT de faire une première valeur effective depuis le "pour toujours", mais puisqu'il n'est pas toujours le cas; nous avons aussi un vilain solution:

J'ai aussi trouvé un LAID option (mais en fait je le recommande, et il résout le problème, donc appelons ça une solution), qui est-ce:

SELECT n.field1, n.field2,
       CASE WHEN NVL(c.EFFDT,n.ISSUE_DT-1)<=n.ISSUE_DT THEN c.field1 ELSE NULL END,
       CASE WHEN NVL(c.EFFDT,n.ISSUE_DT-1)<=n.ISSUE_DT THEN c.field2 ELSE NULL END
FROM MYTABLE N, CUST_OPT C
WHERE  etc...
AND C.SETID           (+) = N.SETID
AND C.CUST_ID         (+) = N.CUST_ID
AND NVL(C.EFFDT,TO_DATE('01011900','DDMMYYYY')) = NVL((SELECT MAX(EFFDT)
                                                       FROM CUST_OPT SC
                                                       WHERE SC.SETID = C.SETID
                                                       AND   SC.CUST_ID = C.CUST_ID
                                                       AND   SC.EFFDT <= N.ISSUE_DT)
                                                     ,NVL( (SELECT MIN(EFFDT)
                                                            FROM CUST_OPT SC
                                                            WHERE SC.SETID = C.SETID
                                                            AND   SC.CUST_ID = C.CUST_ID
                                                            AND   SC.EFFDT >= N.ISSUE_DT)
                                                         ,TO_DATE('01011900','DDMMYYYY')
                                                         )
                                                     )

Cette option SERA de retour l'AVENIR des lignes qui doivent être ignorés! Donc, nous ajoutons les conditions sur l'instruction SELECT qui IGNORE les valeurs renvoyées, si elles n'étaient pas destinées à être récupérées.
Comme je l'ai dit... c'est un VILAIN solution, mais c'est une solution.

Pour mon laid solution, si les lignes seront traitées plus tard dans un Moteur de l'Application ou PL/SQL ou que ce soit; vous pouvez, au lieu d'avoir un CAS de déclaration pour chaque colonne, il suffit d'ajouter une nouvelle colonne à vous dire que vous avez récupéré "irrégulière" des données et d'ignorer les champs plus loin dans votre code, en se basant sur cette colonne, comme ceci:

CASE WHEN NVL(c.EFFDT,n.ISSUE_DT-1)<=n.ISSUE_DT THEN 'N' ELSE 'Y' END AS IGNORE_CUST_OP_COLS

OriginalL'auteur LFLFM

Vous devez vous connecter pour publier un commentaire.