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

[squallJ]

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 :

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(+)

[orafrance]

ça peut être NULL ?

[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?

[McM]

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

[orafrance]

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 :

AND assign.m_post_id = po.post_id

par :

Code :

AND NVL(assign.m_post_id,'NULL') = NVL(po.post_id,'NULL')

[plaineR]

Envoyé par Fred_D

Code :

AND NVL(assign.m_post_id,'NULL') = NVL(po.post_id,'NULL')

Non tu vas obtenir une erreur ORA-01722 - Invalid number

[squallJ]

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.

[squallJ]

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 :

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.

[orafrance]

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é

[orafrance]

c'est bien du number pas du varchar ?

[squallJ]

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.