[ORACLE SQL] NVL geeft geen resultaat

[Verwijderd]

Ik heb een query waarbij ik graag wil dat als een waarde leeg is dat de query toch 0 terug geeft (omdat ik anders de relatie kwijt raak).

Dit is mijn Query:

code:

SELECT TBL_STATWERKVOORRAAD.AFDELING, TBL_STATWERKVOORRAAD.PEILDAG,
TBL_STATWERKVOORRAAD.SOORT_REGELGEVING, TBL_STATWERKVOORRAAD.SOORT_PROCEDURE,
TBL_STATWERKVOORRAAD.STATUSCODE, NVL(SUM
(TBL_STATWERKVOORRAAD.AANTAL_PROCEDURES), 0) AS SUM_AANTPROC FROM 
DBASE.TBL_STATWERKVOORRAAD TBL_STATWERKVOORRAAD WHERE ( 
TBL_STATWERKVOORRAAD.PEILDAG IN (( '20060901' )) )  GROUP BY 
TBL_STATWERKVOORRAAD.AFDELING, TBL_STATWERKVOORRAAD.PEILDAG, 
TBL_STATWERKVOORRAAD.SOORT_REGELGEVING, 
TBL_STATWERKVOORRAAD.SOORT_PROCEDURE, 
TBL_STATWERKVOORRAAD.STATUSCODE

Ik wil dus dat het veld SUM_AANTPROC 0 terug geeft als er geen resultaat is maar dat doet ie nu niet. Gebruik ik de NVL verkeerd?

[justmental]

Je haakjes staan iig. verkeerd.

[Verwijderd]

justmental schreef op maandag 02 oktober 2006 @ 09:24:
Je haakjes staan iig. verkeerd.

Pas het aan........
Je had gelijk. Het originele probleem bestaat overigens nog steeds.

[ Voor 25% gewijzigd door Verwijderd op 02-10-2006 09:41 ]

[Tukk]

Verwijderd schreef op maandag 02 oktober 2006 @ 09:35:
[...]


??? Oh, welke dan?

Als je je query goed uitlijtn zul je dat zefl makkelijk moeten kunnen vinden.

Daarbij, waarom zet je een nvl op een sum, die geeft toch 0 terug als er niets gevonden is?

[Verwijderd]

Tukk schreef op maandag 02 oktober 2006 @ 09:40:
[...]

Als je je query goed uitlijtn zul je dat zefl makkelijk moeten kunnen vinden.

Daarbij, waarom zet je een nvl op een sum, die geeft toch 0 terug als er niets gevonden is?

In dit geval geeft hij niets terug als er niets gevonden word. Snap het zelf ook niet.
Ik wil graag dat bij iedere statuscode een waarde voor de sum wordt terug gegeven, dat doet ie dus niet.

[Verwijderd]

Die nvl werkt wel. Waarschijnlijk levert de voorwaarde geen rij op.

ps. Zie ik nou dat je een datum opslaat in een varchar2 veld???

[justmental]

Als je altijd elke mogelijke statuscode wilt zien, dan zul je moeten outer joinen vanuit een tabel met die statuscodes.

Tukk schreef op maandag 02 oktober 2006 @ 09:40:
Daarbij, waarom zet je een nvl op een sum, die geeft toch 0 terug als er niets gevonden is?

Een sum van niets is null, dus een nvl is daar wel op z'n plaats.

[P_de_B]

Als je ongeacht de records in de tabel TBL_STATWERKVOORRAAD voor ieder record uit de STATUSCODES tabel een record terug wilt moet je niet werken met NVL. Je krijgt gewoon geen record terug als de statuscode niet voorkomt in TBL_STATWERKVOORRAAD.

Je moet selecteren met een tabel waarin alle statuscodes voorkomen, en daarna een LEFT OUTER JOIN met de TBL_STATWERKVOORRAAD tabel doen.

[Verwijderd]

is het veld waarvan je de sum maakt NOT NULL?
Anders zou ik de NVL IN de SUM zetten.

NULL + 5 + 7 + 8 = NULL en daar ga je dan 0 van maken.
Dan ben je beter dat je 0 + 5+7+8 uitrekent denk ik zo...

(verder heb 'k niet zo goed gekeken)

[T-8one]

Verwijderd schreef op maandag 02 oktober 2006 @ 09:43:
[...]


In dit geval geeft hij niets terug als er niets gevonden word. Snap het zelf ook niet.
Ik wil graag dat bij iedere statuscode een waarde voor de sum wordt terug gegeven, dat doet ie dus niet.

Zoals je je code nu hebt levert het resultaat van je sum altijd 0 op als de kolom TBL_STATWERKVOORRAAD.AANTAL_PROCEDURES leeg is.

Wat jij doet: sum(null, 0)
dit is altijd null
pas hierna zet je de NVL functie eromheen.

Wat jij wilt: sum(nvl(TBL_STATWERKVOORRAAD.AANTAL_PROCEDURES, 0))
Als TBL_STATWERKVOORRAAD.AANTAL_PROCEDURES nu null is wordt dit 0 en daar kun je wel verder mee rekenen.

even een paar tips
Om het jezelf makkelijker te maken lijn je code uit het wordt dan veel overzichtelijker.
Je vraagt ook waar de peildag voorkomt in '20060901' beter is volgens mij te zeggen waar deze gelijk is aan, dus gebruik maken van '=' ipv 'in'
Ik neem aan dat TBL_STATWERKVOORRAAD.PEILDAG een varchar veld is, vraag je eens of of het niet beter is een date veld te gebruiken.

ipv de volledige tabelnaam voor elke kolomnaam te zetten kun je ook gebruik maken van een alias waardoor het nog weer wat overzichtelijker wordt
bijvoorbeeld als volgt:

code:

SELECT s.afdeling
FROM    tbl_statwerkvoorraad s

tot zover m'n feedback op je code

[reddevil]

in principe hoeft je helemaal geen aliassen te gebruiken als de tabellen die je queried niet dezelfde kolomnamen hebben maar goed...

Je vraagt ook waar de peildag voorkomt in '20060901' beter is volgens mij te zeggen waar deze gelijk is aan, dus gebruik maken van '=' ipv 'in'

a = b of
a in (b)
is hetzelfde hoor, tis alleen nuttiger bij meerdere values die je zoekt (by dynamisch sql kan het iets uitmaken qua snelheid, maar niet bij precompiled).

Even gelayout (incl nvl fix). Beautifier van PL/SQL Developer is erg handig

SQL:

select afdeling,
       peildag,
       soort_regelgeving,
       soort_procedure,
       statuscode,
       sum(nvl(aantal_procedures, 0)) as sum_aantproc
  from dbase.tbl_statwerkvoorraad
 where peildag = '20060901'
 group by afdeling,
          peildag,
          soort_regelgeving,
          soort_procedure,
          statuscode

[T-8one]

reddevil schreef op dinsdag 03 oktober 2006 @ 14:29:
a = b of
a in (b)
is hetzelfde hoor, tis alleen nuttiger bij meerdere values die je zoekt (by dynamisch sql kan het iets uitmaken qua snelheid, maar niet bij precompiled).

hmm, ik was in de veronderstelling dat een "is gelijk aan" sneller is omdat deze vergelijking optimaler gebruik kan maken van de index.

[reddevil]

kareltje_de_grote schreef op dinsdag 03 oktober 2006 @ 15:01:
[...]


hmm, ik was in de veronderstelling dat een "is gelijk aan" sneller is omdat deze vergelijking optimaler gebruik kan maken van de index.

Maakt zeker weten voor oracle niet uit, de interpreter kiest toch wel de index. Dit is eenvoudig te controleren als je kijkt naar oracle's plan van executie. Het is compiled alleen iets sneller omdat dan de interpreter geen werk meer hoeft te doen.

[ Voor 10% gewijzigd door reddevil op 03-10-2006 15:21 ]

[Phince]

reddevil schreef op dinsdag 03 oktober 2006 @ 15:20:
[...]


Maakt zeker weten voor oracle niet uit, de interpreter kiest toch wel de index. Dit is eenvoudig te controleren als je kijkt naar oracle's plan van executie. Het is compiled alleen iets sneller omdat dan de interpreter geen werk meer hoeft te doen.

Dit maakt zeker wel uit.

Oracle gaat door de in clause werken met een distinct in een subselect wat zal resulteren in een temptabel. en zal dus meer actie moeten doen om de juist waarde(s) te retourneren.

Met de vergelijking van '=' zal oracle deze distinct al niet eens hoeven uit te voeren en dus ook geen temptabel.

p.s.

Kijk ook een naar Bind variabelen.
Dat maakt de query ook een stuk schaalbaarder.


Just my 2 cents.