Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Quanti sono usando Reocrdset DISTINCT e COUNT combinati

Set RS = DB.OpenRecordset("Select Distinct NOME From Log Order By NOME")
Set RS = DB.OpenRecordset("SELECT COUNT(*) AS Quanti FROM LOG",
dbOpenSnapshot)
Come posso combinare il count e il distinct in una sola per sapere quanti
NOMI differenti?
grazie per l'aiutone...
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com
 - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 NOMI differenti?
Set RS = DB.OpenRecordset("SELECT COUNT(DISTINCT NOME) AS Quanti FROM LOG",
dbOpenSnapshot)

 dbOpenSnapshot)
GRRRR a e ZIE!!! 1000
sto impazzendo con la sintassi per fare delle ricerche!
ciao


 dbOpenSnapshot)
Ops...
mi dice SINTAX error operatore mancante...
nella query 'COUNT(DISTINCT NOME)'.
:-((
:-))


 nella query 'COUNT(DISTINCT NOME)'.
SELECT COUNT('DISTINCT DXC')
giusto?
arghhh!
ciao
sry... sono alle prime query!


 sry... sono alle prime query!
In effetti...NO NON FUNZIONA da sempre lo stesso risultato come senza
distinct... azzz! AIUTO!
ciao


 NOMI differenti?
Ottima domanda, non mi era mai capitata la necessità e ne farò tesoro.
Prova con:
Select Count(NOME) As Quanti From (Select Distinct NOME From Log)

 Select Count(NOME) As Quanti From (Select Distinct NOME From Log)
Si PEEERFETTO....
e ho anche aggiunto il WHERE che seleziona ulteriormente e mi da così il
conteggio:
Select Count(NOME) As Quanti From (Select Distinct NOME From Log WHERE CITTA
= 'XXX')
ottimo.. prossima puntata vedo dove mi pianto... :-)))
TNX!


 Select Count(NOME) As Quanti From (Select Distinct NOME From Log)
problemino:
togliendo il "*" ora mi calcola anche il campo vuoto come un record... devo
dirgli WHERE NOME <> '' trim(NOME) <>'' o c'e' di meglio ? sicuro di meglio!
Ho anche un dato da escludere e l'ho inserito co WHERE NOME <> '??'
In quanto uso ?? come default di sconosciuto nel database!
F1 F1 F1,... ma non sempre trovo la soluzione...hi...
Ciao!


 In quanto uso ?? come default di sconosciuto nel database!
where NOME Is Not Null
Ho verificato la sintassi (che non uso mai perchè io non ammetto Null, mi
sembra un assurdo, già detto, tanto tempo fa) con DAO o ADO verso Access.
Sei nelle stesse condizioni?

Where (NOME Is Not Null) And (NOME<>'??')

 nella query 'COUNT(DISTINCT NOME)'.
A me in SQLServer2000 funziona

 Sei nelle stesse condizioni?
Perchè non ammetti il NULL?

puntino . ha scritto:

Perchè, per evitare errori, ti costringono a fare dei test in programma
quando recuperi o usi i valori.
Per me 0 o "" (o, se proprio vogliamo esagerare, dei valori convenzionali)
sono più che sufficienti.

 sono più che sufficienti.
Certo puo' essere che in piu' occasioni dei valori convenzionali possano
risolvere il problema. Tuttavia in generale, come pure in tante
problematiche che a me tocca affrontare per lavoro, il NULL è essenziale. Ma
anche in casi semplici ci si puo' convincere della sua utilità.
Considera pure che spesso valori NULL vengono ritornati automaticamente
dalle query che eseguono dei join tra due o piu' tabelle. Insomma alla fine
tocca sempre, volenti o nolenti, a fare i conti con NULL.

puntino . ha scritto:

Non voglio aprire una polemica, nè ho approfondito il fatto per il quale una
query, comunque fatta, possa restituire dei Null se tutti i campi coinvolti
non contengono Null. Mi piacerebbe capire come sia possibile, ma, come
detto, non ho approfondito.
Da una vecchia discussione, mi par di ricordare che il Null fosse per alcuni
fondamentale per capire se un dato era stato inserito o meno. Credo che per
cifre e date lo 0 (zero) valga tanto quanto il Null, non capisco infatti la
differenza fra una cifra a Null o a 0 per default in quanto non impostata.
Nè capisco la differenza di uno 0 forzato al posto del Null anche se
l'operatore non l'ha esplicitamente impostato. Se nella logica
dell'applicativo il valore 0 è erroneo, credo che lo sia altrettanto il
Null, quindi è l'operatore a non aver indicato un dato fondamentale.
Per le stringhe credo di poter fare lo stesso discorso, ovvero qual è la
differenza o, meglio, l'utilità di un campo a Null piuttosto che a ""
(stringa definita, ma a lunghezza nulla)?
Non comprendo inoltre come si possa distinguere in un form se un certo campo
(textbox destinato a cifre, date o a testo) è vuoto perchè l'operatore non
c'è mai passato sopra o perchè lo ha fatto e magari l'ha svuotato
esplicitamente. A questo punto non è forse un errore depositare Null
piuttosto che "" (o 0) sul database per quel campo?
In sintesi, io faccio così: Quando aggiungo un record (partendo dal
presupposto che non andrò necessariamente ad interessare tutti i suoi campi,
alcuni dei quali magari di competenza di altri forms) pongo tutti i suoi
campi al valore di default (tipicamente 0 per i numerici e "" per i testi,
ma certamente mai Null), quando lo scrivo prelevando i dati da un form
considero 0 tutti i campi del form a destinazione (sul database) numerica
che sono a "0" o a "". Analogamente considero "" tutti i campi del form a
destinazione testo che sono vuoti nel form stesso.
In tutti i miei programmi (salvo tirar giù l'intero calendario quando devo
importare da database di altri e quindi, solo eccezionalmente e localmente
provvedere) non faccio _mai_ un test per Null, semplicemente perchè il Null
per me non esiste mai. Se ci incappo ho un bell'errore e mi sta benissimo
così, so che c'è qualcosa che non va. Credo che l'unica circostanza in cui
devo adottare un piccolo artificio sia (ma non insisto, non ricordo bene la
situazione) per SQL Server e solo per campi Memo (ovvero Text). Questi se
prelevati con variabile=rs!nome_campo e se vuoti (non Null, ma "") generano
un errore. Devo fare quindi variabile="" & rs!nome_campo e sono a posto. Può
anche essere che SQL Server non ponga a "", ma lasci/ponga a Null un campo
Memo/Text pur settandolo esplicitamente a "". Non lo so, nè mi importa più
di tanto.

detto, non ho approfondito.
SELECT tabA.campoX, tabB.campoY
FROM tabA LEFT OUTER JOIN tabB
ON tabA.campoPippo = tabB.campoPluto
tabB.campoPluto ha la foreign key su tabA.campoPippo:
nel caso in tabB non esistano record correlati in tabA per un
determinato valore di tabA.campoPippo allora tabB.campoY sara'
_sicuramente_ NULL.
-- 
ciao, hal

 _sicuramente_ NULL.
Sě, ci stavo pensando, mi torna. E pensandoci mi sono anche ricordato che
quando recupero un recordset da mettere in una griglia provvedo (in una Sub
unica, ormai antica) a risolvere gli eventuali Null. Esplicitamente devo
invece farlo quando devo usare il recordset stesso, ma questi incroci sono,
per me, piuttosto rari. Grazie.

 detto, non ho approfondito.
Immagina di avere due tabelle, ad esempio le seguenti semplicissime:
la tabella CLIENTI
ClienteID  Nome
---------- ----------
1              a
2              b
3              c
4              d
e la tabella Ordini:
ClienteID  OrdineID
---------- ----------
1              1
1              2
4              1
Non tutti i clienti hanno effettuato un ordine, precisamente il clienteID=2
e clienteID=3.
La query seguente:
select clienti.*,ordini.ordineID from clienti
inner join ordini on
clienti.clienteid=ordini.clienteid
recupera tutti i clienti che hanno effettuato almeno un ordine e relativo
OrdineID:
ClienteID  Nome       ordineID
---------- ---------- ----------
1              a              1
1              a              2
4              d              1
Se invece di INNER JOIN metti un LEFT:
select clienti.*,ordini.ordineID from clienti
LEFT join ordini on
clienti.clienteid=ordini.clienteid
otterrai TUTTI i clienti di CLIENTI e relativo ordineID, se pero' questo
esiste!
ClienteID  Nome       ordineID
---------- ---------- ----------
1              a              1
1              a              2
2              b              NULL
3              c              NULL
4              d              1
Infatti ordineID per i clienti 2 e 3 _non_ esistono _non_ avendo questi
ancora effettuato un ordine.
[CUT]
Le considerazioni restanti si dovrebbero rivedere alla luce di quanto sopra.

 Immagina di avere due tabelle, ad esempio le seguenti semplicissime:
Sě, ti ringrazio. Vedi la mia risposta ad Hal. ;-)

 Grazie.
Per Lupo questo ed altro :-)
-- 
ciao, hal

 ancora effettuato un ordine.
salve,
questo resta diverso dal discorso se ammettere o meno il valore NULL come
valore valido all'interno di una tabella e non come risultato di
un'aggregazione o di una intersezione in genere....
questa probabilmente e' una guerra di religione gia' combattuta da altri e
mai vinta, ritengo comunque  il NULL un costrutto sicuramente molto
importante ma altrettanto pericolso, mette in campo una logica a tre valori
che, malgrado corretta ha creato e crea molti problemi, anche di coerenza...
considera l'ipotesi di client non omgenei che intervengano sulla stessa base
dati (anche passando per stored procedures o query per la manipolazione dei
dati stessi)... un client puo' gestire correttamente sia il valore NULL che
la logica ad esso relativo mentre un altro client non lo fa, ma rimpiazza
tale valore con 0, '', etc.... la coerenza stessa della base dati risulta
compromessa... il valore 0 presente nel campo e' realmente uno 0 (con tutto
cio' che la valorizzazione comporta) ovvero e' un NULL, con tutto cio' che
la NON valorizzazione comporta???
personalmente spesso tendo ad utilizzare l'approccio di Lupo, fornendo dei
valori di default e non accettando il NULL a livello di DDL, che tra gli
altri anche Joe Celko consiglia, specialmente in caso di dubbio  (avete
notato la sua somiglianza con il cattivo imperatore Ming di Flash Gordon??)
addirittura, il Dr. Codd aveva previsto 2 tipi di NULL nel suo grande
disegno, uno per il valori che dovrebbero essere presenti nel campo ma per
qualche motivo non lo sono (ad es. la valorizzazione del campo "sesso" M/F
di una persona), ed i valori che non ci sono perche' NON dovrebbero essere
presenti (il campo "sesso" M/F di una societa'), per cui un NULL che
identifica un valore sconosciuto, ed un altro che identifica un valore non
applicabile....
peggio ancora, un'analisi ANSI X3 prevedeva 14 tipologie differenti di dati
incompleti (nulls) derivanti dal risultato di operazioni, ovvero
dall'attribuzione dei valori, tra gli altri underflow e overflow matematici,
divisioni per 0, troncamento di stringhe, elevamento di 0 a potenza di
0......
per fortuna ne e' sopravvissuto uno solo....
al di la' della teoria, in generale e' difficile rappresentare il valore
NULL, anche, come Lupo riporta, ad esempio in una form di
inserimento/modifica.... all'utente finale, che differenza passa tra l'avere
il campo "sesso" non valorizzato perche' sconsciuto o perche' l'utente
precedente non l'ha messo??
ho spesso sentito dire che il valore NULL e' la kriptonite dei Database,
anche se necessario in alcuni casi (molto spesso con le date)
al di la' di tutto cio', i caricamenti dei GUI da recordset normalmente li
proteggo semplicemente con txtCampo.Text = ("" &
objRecordSet.Field("zz").Value) ovvero con isnull(...)
my $0.02
Andrea Montanari
montanar...@virgilio.it
http://www.asql.biz/DbaMgr.shtm
DbaMgr2k ver 0.2.0  -  DbaMgr ver 0.48.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
--------- remove DMO to reply

 precedente non l'ha messo??
Io ragiono cosi'. In entrambi i casi il campo sesso è stato omesso e ciò per
uno di due possibili motivi:
1) non è noto
2) non è applicabile
In fase di scrittura del record io valorizzerei il campo corrispondente con
NULL.
[CUT]

 NULL.
Io ragiono così: Se il campo sesso non è applicabile (nell'esempio, che
faceva Andrea, di una persona giuridica) non pongo nemmeno la richiesta, la
tolgo proprio dalla maschera e non ne userò mai il suo campo sul db che, a
quel punto, può avere qualsiasi valore (non Null). Se applicabile lo
propongo a uno dei possibili valori (default) e mi limito a registrare
quanto l'operatore accetta o esplicitamente indica. A parziale rettifica del
mio primo post sull'argomento, dove davo la colpa all'operatore che non
aveva indicato un dato fondamentale, mi correggo e dico che se un dato
obbligatorio (di valore contestualmente corretto) non viene impostato, la
colpa è del programmatore, non dell'operatore.
Mi voglio togliere anche una piccola (quanto magra) soddisfazione: Perchè in
VB e in SQL (salvo forse i risultati di Query Analyzer, non so in altri
linguaggi) un valore Null non viene automaticamente rappresentato in termini
grafici (per esempio su un form o in una griglia) con qualche simbolo
particolare? Che ci voleva? Non l'hanno fatto loro, perchè dovrei (come
troppo spesso accade) farlo io? Null, vade retro! ;-)))

Una cosa è certa, da questo ragionamento non se ne esce piu', per cui io mi
fermo!:)
Lasciami pero' fare un'ultima considerazione.
Di fatto il NULL esiste, che vuoi farci?! Capisco che a sviluppare un
applicativo per proprio conto se ne puo' anche fare a meno, ma se lavori in
team e il tuo analista questo NULL lo vuole..........che ci vuoi fare?!

 team e il tuo analista questo NULL lo vuole..........che ci vuoi fare?!
Lasciami il diritto di replica (non l'ultima parola) ;-)
L'ho già detto: trovo inconcepibile che esista, nel senso che in origine
qualcuno l'abbia voluto. E', sempre IMHO, un assurdo. Ribadisco: la
rappresentazione del nulla con qualcosa. Un controsenso! Io ho deciso di non
usarlo e, come dicevo, quando lo incontro tiro giù l'intero calendario.
Rispetto quell'analista, ma, insomma, ... finchè posso, io faccio l'analista
e il programmatore. Spesso anche il commerciale.
Ciao. Comunque, bella discussione, che, proprio per questo, non ha cambiato
di una virgola le rispettive posizioni ;-))

di una virgola le rispettive posizioni ;-))
Ci nancherebbe, lo scopo della discussione deve essere la reciproca
crescita, mica la coercizione delle convinzioni altrui :-)
-- 
ciao, hal

 crescita, mica la coercizione delle convinzioni altrui :-)
Vero, ma intendevo dire (in una botta di filosofia) che le discussioni che
portano a un cambiamento radicale di una posizione (o, peggio, di più
posizioni, s'è già visto anche questo), sono generalmente discussioni su
argomenti "meno importanti". Non questa.

 software deve essere prodotto ed utilizzato.
Urka... mi scuso per aver avviato un "monsTRe" sul NULL & '' ...
ma tornando al TR d'inizio, dopo aver letto con interesse tutte le varie PRO
CONTRO e BOH...
Se io nella mia ricerca gli sbatto dentro
where NOME Is Not Null
al posto del
WHERE nome <>''
ho due risultati diversi.
Il primo mi calcola ugualmente il campo "vuoto" mentre con '' non lo
"prende" affatto...
e questa non l'ho capita...
ciao


 "prende" affatto...
Direi il contrario, ma (e qui si scatena un'altra guerra di religione, cosa
che conferma il mio pensiero sui Null) non ne sono affatto sicuro, io (:PPP)
i Null non li ammetto.