Oracle SQL - Le code non nul ne fonctionne pas

Vous n'avez pas de valeurs nulles mais des espaces vides, ajoutez ci-dessous dans votre requête

 SELECT project_id, monetary_amount, 
  journal_line_date 
  FROM PS_JRNL_LN 
    where ( project_id is not null or
   ( project_id is not 
     null   
    and  LTRIM( RTrim(project_id)) not 
       like '') 
     and 
     journal_line_date BETWEEN 
     to_date ('2020/01/01','yyyy/mm/dd') 
                        AND TO_DATE 
   ('2020/03/04','yyyy/mm/dd')

Voici quelque chose qui peut vous aider à découvrir ce qui se passe dans la colonne project_id . (Très probablement, un tas de valeurs '' , c'est-à-dire une chaîne non vide composée d'un seul espace.)

where project_id != ' '

DUMP s'affiche vous exactement ce qui est stocké dans votre table. 32 est le code ASCII pour un seul espace; 9 (ou 09) est le code de la tabulation horizontale. J'espère que vous obtiendrez des lignes où la colonne DUMP montre un seul caractère, avec le code 32. Mais - qui sait; vous pouvez également trouver d'autres choses.

Cela vous aidera à comprendre ce qu'il y a dans la colonne. (Vous pouvez également vérifier décrire ps_jrnl_ln - vous découvrirez peut-être que la colonne est déclarée non nulle !!!)

Si vous trouvez un tas de lignes où l'ID du projet est un seul espace, bien sûr, dans votre requête réelle, vous devrez remplacer

where ltrim(project_id, chr(32) || chr(9)) is not null

par

where project_id is not null

Ou, peut-être, si en effet un seul espace est utilisé comme espace réservé pour null:

select project_id, dump(project_id)
from   ps_jrnl_ln
where  ltrim(project_id, chr(32) || chr(9)) is null
  and  project_id is not null
;

Peu de choses que vous devez mettre en œuvre dans la conception de votre table pour éviter le problème en premier lieu que de lutter avec les données:

1. Ajoutez une contrainte NOT NULL à la colonne.
2. Ajoutez une contrainte CHECK pour empêcher les caractères indésirables tels que les espaces blancs, etc. et autoriser uniquement les données que vous souhaitez charger.
3. Si vous ne souhaitez pas de contrainte de vérification, gérez-la lors du chargement des données à l'aide de TRIM .
4. Si nécessaire, faites de la colonne PROJECT_ID la clé primaire, cela n'autoriserait implicitement pas les valeurs NULL. Habituellement, la colonne ID dans un tableau suggère qu'il s'agit d'une clé primaire, mais cela peut varier selon votre cas d'utilisation.

Si vous n'êtes pas autorisé à modifier la conception en n'effectuant aucune des actions ci-dessus, vous pouvez au moins gérer l'insertion de données au niveau de l'application où vous pourriez les prendre comme entrée.

Essayez d'utiliser la condition de filtre:

ltrim(rtrim(project_id)) <> ''

Inner joint cette table journal à la source de vérité pour les ID de projet. En supposant qu'il n'y ait pas d'identifiant "vide" dans ce tableau, alors vous n'obtiendrez pas de "blanc" dans votre résultat.

par exemple

SELECT j.project_id, j.monetary_amount, j.journal_line_date 
FROM PS_JRNL_LN J

  INNER JOIN PROJECT_MASTER P ON j.project_id = p.id /* should remove "blanks" */

where j.journal_line_date >= to_date ('2020/01/01','yyyy/mm/dd') 
and  j.journal_line_date < TO_DATE ('2020/03/05','yyyy/mm/dd')

Notez également que je n'utilise jamais entre pour les plages de dates, le modèle ci-dessus utilisant > = & est plus fiable (car il fonctionne quelle que soit la précision temporelle des données) .