Newsgroup: it.comp.appl.access
Titolo: Valore null in query...

Salve, avrei bisogno gentilmente di un vostro parere su una cosa che non 
riesco a spiegarmi..... Allora, ho 1 tabelle con vari campi, testo, 
numerico, data etc., con  questa tabella creo due query e nel campo numerico 
faccio il raggruppamento e chiedo la somma (tutto regolare fin qui... i 
risultati tornano !!), da queste 2 query, faccio una terza query che mi 
faccia la differenza delle 2 somme presenti nelle due query precedenti (una 
specie di giacenza di magazzino), allora il problema è che anche se il join 
è il numero 2 (cioè includi tutti i record di query... e solo quelli di ... 
in cui i campi sono uguali), il campo calcolato rimane vuoto; se metto la 
condizione che se è vuoto mi deve mettere 0 così fa la sottrazione, ma ciò 
non è valido, perchè se vado a vedere le 2 query d'origine, i campi non 
risultano vuoti !!!! Possibile che sia un problema di formato numerico ??? 
Nelle tabelle il campo numerico e intero lungo, e come valore predefinito 
nel campo quantità ho messo 1. Grazie. 

 ha scritto nel messaggio
news:fesSd.934570$35.35...@news4.tin.it...

Ciao Romeo,
devi utilizzare per restituire 0 quando un campo è null la funzione nz.
differeza:nz(campo1]-[campo2];0)
Controlla anche l'help per la funzione NZ
Ciao

 ha scritto nel messaggio
news:fesSd.934570$35.35...@news4.tin.it...

Ciao Romeo,
non è un problema di formato numerico, tu hai usato la Query1 in LEFT OUTER
JOIN con Query2, se non c'è corrispondenza nella relazione la somma
calcolata in Query2 non esiste quindi viene restituito NULL.
Può essere che un prodotto abbia solo carichi quindi esiste in Query1 ma se
non è mai stato scaricato non esiste in Query2 quindi viene restituito NULL
come valore di scarico.
Attenzione che se le parti si invertono la cosa diventa più complicata e
rischi di non vedere i prodotti con giacenza negativa (ammesso che possano
esistere) comunque a parte questo aspetto applica il suggerimento di Sandro
per calcolare la differenza tra i due valori.
Ciao Giorgio

 ha scritto nel 
messaggio news:421a5590$0$6300$5fc...@news.tiscali.it...

Grazie ragazzi, ma non ci siamo.... Allora sia nel primo caso, cioè quello 
che ha detto Sandro e quello che hai detto tu non funziona, il campo è 
sempre vuoto, anche se uso la funzione NZ. La cosa strana, è che esiste sia 
un carico con 6 pezzi che uno scarico con un pezzo. Non ne vuole sapere !!! 
Sempre vuoto. Se metto la condizione nz(carico]-[scarico];0), mi restituisce 
0 (zero), ma non è vero, perche con lo stesso codice esite una vendita, 
quindi 6-1=5 ma non vuole uscire. Ho notato però, che in alcuni casi su 
altri record della stessa tabella funziona, in alcuni no !!!! Grazie se 
avete altre idee. 

 ha scritto nel messaggio
news:k4MSd.577982$b5.26...@news3.tin.it...

Ciao Romeo,
l'unica cosa che mi viene in mente è che potrebbero esserci dei campi null
in una delle due query dove calcoli la somma.
Potrebbe essere una spiegazione visto che dici che in alcuni casi funziona.
Non è che ci sono dei left outer join nelle query di partenza e non ha
considerato che anche li devi utilizzare nz ?
Ciao


Ciao Romeo,
dunque la cosa si fa fitta... dovresti controllare che le singole query che
sommano rispettivamente il carico e lo scarico restituiscano effettivamente
i dati, poi se mettendole in OUTER JOIN non restituiscono il risultato
aspettato dovresti provare a compattare il database.
In passato mi è capitato spesso che  l'esecuzione di query complesse su
databases molto frammentati non rendessero il risultato corretto.
Ciao Giorgio

 ha scritto nel 
messaggio news:421b990c$0$32337$5fc...@news.tiscali.it...

Ciao a tutti, allora ho visto nelle 2 query che oltre alla somma nel campo 
della quantità, non ci sono altro che "raggruppamento" o "ultimo" ovviamente 
altro non ci può essere !!! Quindi il problema non credo che sia questo ! Le 
singole query, restituiscono tutte il valore, anche perchè dentro c'è solo 
un numero e non fa che, quando chiedo il raggruppamento, la somma di quei 
valori. Il problema sta nel fatto che quando faccio la terza query, basata 
sulle due in questione (carico e scarico) e uso "NZ....." o simile funzione, 
anche mettendo la condizione che 'if scarico is null ;0' lui esegue la 
condizione e mi mette zero, ma poi aprendo la query di scarico noto che per 
quel barcode il valore non era null ma ad esempio 1. Ho anche compattato il 
database, (ripristina e compatta), ho anche importato tabella e query in un 
nuovo .mdb, ma il risultato non cambia !! Sicuramente c'è qualcosa di 
sbagliato o nei formati o nei raggruppamenti, ma cosa ? Non riesco proprio a 
vederlo !!! Sono pronto, se siete così disponibili, anche ad inviarvi il 
database. Grazie ancora e Ciao. 


sono proprio curioso, se vuoi togli  _No_Spalmer_ dal mio indirizzo e
mandami il Db.
Ciao Giorgio

 ha scritto nel messaggio
news:Wt1Td.945190$35.35...@news4.tin.it...

Ciao Romeo
ho postato dal pc dell'ufficio, ma non vedo il post.
Se vuoi mandarlo anche a me, lo guardo molto volentieri.
Ciao

 ha scritto nel messaggio
news:Wt1Td.945190$35.35...@news4.tin.it...

Ciao Romeo,
Se vuoi mandami il tuo mdb.Sono molto curioso.
Non all'indirizzo che trovi in questo post, ma a quello che trovi nei post
dei giorni precedenti.
Tra max 1ora e mezza ti rispondo.
Ciao

 > [CUT]
[CUT]
Romeo,
il comportamento della query è del tutto normale.
Se metti in left join oltre al campo [Barcode] anche il prezzo di acquisto e
il prezzo di vendita non ti ritroverai i record con prezzo acquisto o
vendita diverso (e ce ne sono diversi)
Scusa ma a me sembra un modo bizzarro per rilevare le giacenze, io metterei
in left join solo l'Id del negozio e il barcode se lo scopo è avere le
giacenze per ogni negozio.
Ciao Giorgio

 ha scritto nel 
messaggio news:421ce391$0$32342$5fc...@news.tiscali.it...

Ciao Giorgio,
capisco che la cosa è un pò bizzarra, ma come ho già spiegato a Sandro per 
e-mail, purtroppo questo database l'ho ereditato ed è nato veramente male, 
forse chi lo ha fatto non sapeva nemmeno che esistessero delle relazioni e 
delle condizioni ben precise. Comunque proverò ad arrangiarmi perchè 
effettivamente ci sono delle non corispondenze tra i dati. Grazie per la 
partecipazione.
Ciao, Romeo.