IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Oracle Discussion :

Problème de comparaison de numbers avec =, mais OK avec LIKE


Sujet :

Oracle

  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    55
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2005
    Messages : 55
    Points : 61
    Points
    61
    Par défaut Problème de comparaison de numbers avec =, mais OK avec LIKE
    Version: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0

    Bonjour,

    J'ai un drole de résultat à l'execution de la requète suivante:
    Il ne me retourne pas de tuple, mais lorsque je mets un LIKE à la place du signe = au niveau de la comparaison des postes , cela fonctionne.

    Cela fonctionne avec le signe = dans les conditions suivantes :
    Si on met en commentaire une des 2 requetes de l'union ou si on fait assign.m_post_id = po.post_id(+)
    Le type de post_id est identique dans toutes les table, c'est du number(6).

    Comment cela se fait-il?

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    SELECT po.* 
        FROM P_BREAK_PERIODS bp
       , P_PERSONS pe
       , (SELECT a.start_date
    	       , a.end_date 
    	       , a.m_post_id 
    		   , a.person_id 
    	  FROM P_ASSIGNMENTS a
    	  WHERE a.sequence <> 99999
    	  UNION
    	  SELECT c.start_date  
    		   , c.end_date
    		   , c.m_post_id 
    		   , c.person_id
          FROM P_CONTRACTS c) assign
       , M_POSTES po
       , P_ABSENCE_TYPES a
     WHERE pe.person_id = bp.person_id
       AND pe.person_id = assign.person_id
       AND assign.m_post_id = po.post_id
       AND TRUNC(NVL(bp.end_date,SYSDATE)) >= TRUNC(assign.start_date)
       AND TRUNC(bp.start_date) <= TRUNC(NVL(assign.end_date,SYSDATE))
       AND bp.absence_tp_id = a.absence_tp_id(+)

  2. #2
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 075
    Points
    19 075
    Par défaut
    ça peut être NULL ?

  3. #3
    Membre du Club
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    55
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2005
    Messages : 55
    Points : 61
    Points
    61
    Par défaut
    Oui , il se peut que le post_id soit null.
    Mais normalement , même si il y a des NULL, il doit tout de même retourné ceux dont la comparaison était OK non?

  4. #4
    McM
    McM est déconnecté
    Expert éminent

    Homme Profil pro
    Développeur Oracle
    Inscrit en
    Juillet 2003
    Messages
    4 580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Oracle

    Informations forums :
    Inscription : Juillet 2003
    Messages : 4 580
    Points : 7 740
    Points
    7 740
    Billets dans le blog
    4
    Par défaut
    Tu peux essayer de réduire ta requete (en nombre de tables annexes) pour ne garder que "assign" et "po" ?

    Ensuite faudrait trouver un cas qui est ramené par le like et pas par le =
    et afficher toutes les colonnes qui sont dans ta requete dans le SELECT

  5. #5
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 075
    Points
    19 075
    Par défaut
    Citation Envoyé par squallJ
    Oui , il se peut que le post_id soit null.
    Mais normalement , même si il y a des NULL, il doit tout de même retourné ceux dont la comparaison était OK non?
    Dans ce cas une égalité avec NULL est forcément fausse

    Remplace :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    AND assign.m_post_id = po.post_id
    par :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    AND NVL(assign.m_post_id,'NULL') = NVL(po.post_id,'NULL')

  6. #6
    Membre expert

    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Janvier 2004
    Messages
    2 862
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2004
    Messages : 2 862
    Points : 3 609
    Points
    3 609
    Par défaut
    Citation Envoyé par Fred_D
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    AND NVL(assign.m_post_id,'NULL') = NVL(po.post_id,'NULL')
    Non tu vas obtenir une erreur ORA-01722 - Invalid number

  7. #7
    Membre du Club
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    55
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2005
    Messages : 55
    Points : 61
    Points
    61
    Par défaut
    Tu peux essayer de réduire ta requete (en nombre de tables annexes) pour ne garder que "assign" et "po" ?

    Ensuite faudrait trouver un cas qui est ramené par le like et pas par le =
    et afficher toutes les colonnes qui sont dans ta requete dans le SELECT
    En fait le = ne retourne aucun tuples McM.

  8. #8
    Membre du Club
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    55
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2005
    Messages : 55
    Points : 61
    Points
    61
    Par défaut
    Je viens de vérifié, assign ne contient pas de valeur NULL pour le m_post_id, le person_id et la table M_POSTES n'en contient pas non plus.

    En fait Nous avons une base "bidev" avec un shema perallApp.
    Il y a une autre base "devdb" avec les shemas Master et Perall.
    Dans PerallApp de bidev, il y a toutes les procédures,fonctions,... et dans les shemas de devdb, il y a toute les datas.

    PerallApp accède aux data grace à des synonyms contenant un dblink.
    Style: synonym P_PERSONS FOR P_PERSONS@PERALL_DATA
    synonym M_POSTES FOR M_POSTES@MASTER_DATA

    Je viens de remarqué que lorsque j'exécute la requète sur "devdb" dans le shema Perall, cela fonctionne correctement.

    Je ne sais pas si le fait de travaillé par dblink peut faire "déconné" le système mais il y a tout de même de drôle de réactions car
    Si dans le code de la requète, on mets en commentaire
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
       AND TRUNC(NVL(bp.end_date,SYSDATE)) >= TRUNC(assign.start_date)
       AND TRUNC(bp.start_date) <= TRUNC(NVL(assign.end_date,SYSDATE))
       AND bp.absence_tp_id = a.absence_tp_id(+)
    cela fonctionne correctement et comme je le disai au début, si on ne met pas ses lignes en commentaire mais que l'on place un LIKE pour les m_post_id , on obtient le résultat voulu.

  9. #9
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 075
    Points
    19 075
    Par défaut
    Citation Envoyé par plaineR
    Non tu vas obtenir une erreur ORA-01722 - Invalid number
    en principe il est capable de faire la conversion comme un grand mais on remplace 'NULL' par -1 est c'est réglé

  10. #10
    Expert éminent sénior
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Points : 19 075
    Points
    19 075
    Par défaut
    c'est bien du number pas du varchar ?

  11. #11
    Membre du Club
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    55
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2005
    Messages : 55
    Points : 61
    Points
    61
    Par défaut
    Oui , c'est bien du Number(6) pour tout les id.
    Mais c'est comme j'écrivais plus haut, suivant le shéma dans lequel j'exécute cette requète, cela fonctionne bien ou pas.

    Donc je vais un peu demandé demain matin au DBA comment cela peut-il se produire.

    Merci quand même pour votre investissement.
    Si j'ai une solution , je la posterai.

Discussions similaires

  1. Excel retourne valeur avec "=" mais pas avec ">="
    Par Kedash dans le forum Macros et VBA Excel
    Réponses: 11
    Dernier message: 04/02/2015, 18h59
  2. Problème de comparaison de curdate() avec un datetime
    Par dubitoph dans le forum Requêtes
    Réponses: 2
    Dernier message: 29/07/2009, 16h53
  3. Réponses: 1
    Dernier message: 09/10/2007, 06h44
  4. Réponses: 1
    Dernier message: 03/08/2007, 10h09
  5. Réponses: 12
    Dernier message: 28/05/2007, 04h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo