campi NULL e BLANK ( vuoti)
Gerry
valore NULL , sono vuoti ( bianchi).
Quindi la mia condizione Where [nomecampo] is not NULL non funziona in
tali casi .
Mi chiedevo come risolvere: impostare prima una query che inserisca NULL
dove non vi č alcun dato ( č possibile? ) , oppure se conoscete una
sintassi che consideri i campi in bianco.
Buonasera
Giacomo Degli Esposti
> MS SQL SERVER 2005 : in una tabella alcuni campi anzich contenere il
> valore NULL , sono vuoti ( bianchi).
>
> Quindi la mia condizione Where [nomecampo] is not NULL non funziona in
> tali casi .
>
> Mi chiedevo come risolvere: impostare prima una query che inserisca NULL
> sintassi che consideri i campi in bianco.
Ciao,
immagino che bianchi significhi che sono stringhe vuote... in questo
caso
puoi usare
where [nomecampo] <> ''
Se hai campi in cui in certe righe hai null e in altre hai '' puoi
scrivere
where isnull( [nomecampo], '') <> ''
(sconsigliabile in quanto le performance calano parecchio perche non
riuscirebbe ad usare eventuali indici)
ciao
Giacomo
Gerry
<immagino che bianchi significhi che sono stringhe vuote... in questo
<caso
<puoi usare
<where [nomecampo] <> ''
<Se hai campi in cui in certe righe hai null e in altre hai '' puoi
<scrivere
<where isnull( [nomecampo], '') <> ''
non dovresti usare l'operatore OR ?
Ad esempio se volessi selezionare le righe con il campo NULL oppure con il
campo VUOTO :
Where ( ( [nomecampo] is NULL ) OR ( [nomecampo] ='' ) )
Giacomo Degli Esposti
[...]
> <where isnull( [nomecampo], '') <> ''
>
> non dovresti usare l'operatore OR ?
>
> Ad esempio se volessi selezionare le righe con il campo NULL oppure con il
> campo VUOTO :
>
> Where ( ( [nomecampo] is NULL ) OR ( [nomecampo] ='' ) )
Si puoi fare anche cosi' (pure meglio perche e' sql standard e non usi
funzioni
specifiche di MSSQL :)
ciao
Giacomo
David Martin
>> <where isnull( [nomecampo], '') <> ''
>
> non dovresti usare l'operatore OR ?
> Ad esempio se volessi selezionare le righe con il campo NULL oppure con il
> campo VUOTO :
> Where ( ( [nomecampo] is NULL ) OR ( [nomecampo] ='' ) )
Sono due istruzioni diverse, quella che hai scritto tu e quella che ti
aveva proposto Giacomo.
Vanno bene entrambe, quindi non è che "dovresti" usare l'OR,
semplicemente hai la possibilità di usare entrambe le sintassi.
Quella di Giacomo però è specifica di SQL Server, in Mysql dovresti
usare IFNULL al posto di ISNULL.
Attenzione però che NULL e "stringa vuota" non hanno nulla a che vedere
l'uno con l'altro...
--
David Martin
Gerry
>
> Attenzione però che NULL e "stringa vuota" non hanno nulla a che vedere
> l'uno con l'altro...
con Microsoft sql server ho fatto questa interessante scoperta : se il
campo [data_documento] ammette valori blanck ( oltre che valori NULL )
allora l'istruzione
where ( ([data_documento] is not null ) OR ([data_documento] <>'')
ha significato , cioè distingue i due valori ( null e blanck) ;
se invece il campo non ammette valori blanck ( a causa di un vincolo) ,
l'istruzione riportata è perfettamente equivalente a questa
where ( ([data_documento] is not null )
In tale secondo caso ( il campo non ammette valori blanck ) il risultato è
sorprendente , in quanto l'struzione :
where ( ([data_documento] is not null ) OR ([data_documento] <>'')
non dovrebbe filtrare alcunchè in quanto è sempre vera!
Invece esclude i campi NULL !
Vi risulta?
Ciao
David Martin
> se invece il campo non ammette valori blanck ( a causa di un vincolo) ,
> l'istruzione riportata è perfettamente equivalente a questa
>
> where ( ([data_documento] is not null )
>
>
> In tale secondo caso ( il campo non ammette valori blanck ) il risultato è
> sorprendente , in quanto l'struzione :
>
> where ( ([data_documento] is not null ) OR ([data_documento] <>'')
>
> non dovrebbe filtrare alcunchè in quanto è sempre vera!
Se mi spieghi il motivo per cui dovrebbe essere sempre vera, ti rispondo.
> Invece esclude i campi NULL !
Beh, gliel'hai detto tu di escludere i valori NULL, scrivendo WHERE
campo IS NOT NULL.
Ripeto quanto ho scritto nell'altro post: i NULL non hanno niente a che
vedere con il campo "vuoto".
--
David Martin
Gerry
>>
>> non dovrebbe filtrare alcunchè in quanto è sempre vera!
>
> Se mi spieghi il motivo per cui dovrebbe essere sempre vera, ti rispondo.
il secondo elemento dell'OR è sempre vero ( tutte le date ovviamente non
sono blanck,proprio per via del vincolo presente sul campo) ;
e siccome F OR V = V
e V OR V = V
la clausola WHERE diventa manifestamente inutile.
>
> Beh, gliel'hai detto tu di escludere i valori NULL, scrivendo WHERE
> campo IS NOT NULL.
no , io messo la condizione WHERE ( F OR V )
> Ripeto quanto ho scritto nell'altro post: i NULL non hanno niente a che
> vedere con il campo "vuoto".
questo è vero , ai fini delle query, solo se il campo ammette valori Blanck;
altrimenti null e blanck sono indistinguibili .
Gerry
>
> questo è vero , ai fini delle query, solo se il campo ammette valori
> Blanck;
> altrimenti null e blanck sono indistinguibili .
infatti se il campo ammette valori blanck , le condizioni
where [nomecampo] <> ''
e
where [nomecampo] is not null
sono diverse , e filtrano record diversi.
Paolo opg
>
>
>>
>> Attenzione però che NULL e "stringa vuota" non hanno nulla a che
>> vedere l'uno con l'altro...
>
>
>
> con Microsoft sql server ho fatto questa interessante scoperta : se
> il campo [data_documento] ammette valori blanck ( oltre che valori
> NULL ) allora l'istruzione
>
> where ( ([data_documento] is not null ) OR ([data_documento] <>'')
>
> ha significato , cioè distingue i due valori ( null e blanck) ;
>
> se invece il campo non ammette valori blanck ( a causa di un vincolo)
> , l'istruzione riportata è perfettamente equivalente a questa
>
> where ( ([data_documento] is not null )
>
se il campo data ammette valori blank (dove blank = '') imo c'e' qualcosa
che non quadra, perche' a meno di esigenze particolari e necessita'
stringenti, un campo data su mssql dovrebbe essere di tipo smalldatetime
o datetime.
e in quel tipo dati una stringa non ci entra proprio...
>
> In tale secondo caso ( il campo non ammette valori blanck ) il
> risultato è sorprendente , in quanto l'struzione :
>
> where ( ([data_documento] is not null ) OR ([data_documento] <>'')
>
> non dovrebbe filtrare alcunchè in quanto è sempre vera!
>
> Invece esclude i campi NULL !
>
> Vi risulta?
>
> Ciao
>
>
>
a naso a me sembra il comportamento previsto.
http://www.devx.com/vb2themax/Tip/18541
--
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--
Lucazeo
Più standard: where COALESCE( [nomecampo], '') <> ''
Però su sqlserver, stando alla documentazione, ISNULL è più
performante.
Personalmente penso che sia irrilevante creare applicazioni che magari
sono custom, pensando alla portabilità del db: non sfrutteresti mai
fino in fondo l'engine del db. Ma questo è un altro discorso.
> ciao
> Giacomo
Ciao,
Lucazeo.
David Martin
> il secondo elemento dell'OR è sempre vero ( tutte le date ovviamente non
> sono blanck,proprio per via del vincolo presente sul campo) ;
Scusa, mi son un attimo perso e non mi ero ricordato che stavamo
parlando di campi di tipo data.
Tuttavia, quello che scrivi non mi convince: posta lo script di
creazione della tabella, almeno un paio di record di test e poi le
istruzioni di selezione, che vediamo di riprodurre il "problema".
A quanto mi risulta, nei campi di tipo 'data' non esiste in blank... il
campo è NULL oppure ha un valore che hai definito tu oppure ha il valore
'1900-01-01 00:00.000'.
Se hai una tabella con un campo di tipo 'date' e inserisci il valore
"blank" '', quindi fai una select, il motore ti restituisce la data
'1900-01-01'.
>> Ripeto quanto ho scritto nell'altro post: i NULL non hanno niente a che
>> vedere con il campo "vuoto".
>
> questo è vero , ai fini delle query, solo se il campo ammette valori Blanck;
> altrimenti null e blanck sono indistinguibili .
Non bestemmiamo per favore. :-)
NULL e blank sono cose completamente diverse, punto.
--
David Martin
Gigi
> Tuttavia, quello che scrivi non mi convince: posta lo script di
> creazione della tabella, almeno un paio di record di test e poi le
> istruzioni di selezione, che vediamo di riprodurre il "problema".
purtroppo lavoro su un database fatto da altri,io mi sto limitando a
modificarlo tramite query , e mi sono accorto appunto del differente
comportamento per le colonne di tipo data rispetto ad altre colonne che
ammettono valori blanck.
Grazie comunque
Ciao
David Martin
Beh, anche se il db è di altri, non puoi vedere qual'è la struttura?
Fino a prova contraria, la mia opinione è che c'è qualcosa che sfugge a
te e non a SQL Server...
--
David Martin
Gerry
> Fino a prova contraria, la mia opinione è che c'è qualcosa che sfugge a
> te e non a SQL Server...
segue la struttura della tabella ( CG.TESTA )su cui eseguo le query .
le query eseguite sul campo [Data_Documento] non distinguono tra valore NULL
e '' , mentre invece quelle eseguite sul campo [ID_RegIVA] sì.
Ciao
USE [database]
GO
/****** Oggetto: Table [dbo].[CG_Testa] Data script: 12/15/2010 17:14:44
******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[CG_Testa](
[ID_Azione_Ins] [int] NULL,
[ID_Azione_Mod] [int] NULL,
[N_IDAzienda] [int] NOT NULL,
[ID_Movim_CG] [int] NOT NULL,
[Tipo_Movimento] [varchar](1) NULL,
[Data_Registrazione] [datetime] NULL,
[Data_Comp_Esercizio] [datetime] NULL,
[Data_Comp_LiqIVA] [datetime] NULL,
[Data_Documento] [datetime] NULL,
[Num_Documento] [varchar](10) NULL,
[ID_Causale] [varchar](4) NULL,
[Descrizione] [varchar](40) NULL,
[ID_Provvisorio] [varchar](2) NULL,
[ID_Tipo_Pagamento] [varchar](1) NULL,
[ID_Pagamento] [varchar](3) NULL,
[ID_RegIVA] [varchar](2) NULL,
[Prot_IVA] [varchar](10) NULL,
[ID_Immagine] [int] NULL,
[ID_RegIVA_Vendite] [varchar](2) NULL,
[Prot_IVA_Vendite] [varchar](10) NULL,
[Prog_Stampa_RU] [int] NULL,
[Pag_Stampa_RU] [int] NULL,
[ID_Attivita] [varchar](2) NULL,
[ID_Filiale] [varchar](2) NULL,
CONSTRAINT [PK_CG_Testa] PRIMARY KEY CLUSTERED
(
[N_IDAzienda] ASC,
[ID_Movim_CG] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
David Martin
> segue la struttura della tabella ( CG.TESTA )su cui eseguo le query .
>
> le query eseguite sul campo [Data_Documento] non distinguono tra valore NULL
> e '' , mentre invece quelle eseguite sul campo [ID_RegIVA] s�.
Sinceramente temo tu abbia una gran confusione in testa riguardo a
questo argomento...
I campi di tipo stringa (nel tuo caso [ID_RegIVA]), e NULLABLE,
ammettono i seguenti valori:
1. NULL
2. un valore specificato dall'utente (o un default).
In questa seconda categoria rientra il campo "vuoto".
I campi di tipo data/ora (nel tuo caso [Data_Documento]), e NULLABLE,
ammettono i seguenti valori:
1. NULL
2. un valore specificato dall'utente (o un default).
Non puoi inserire una "data vuota".
Come gi� indicato in un altro post, se in una data tu inserisci il
valore '', SQL Server memorizza la sua data iniziale '1970-01-01 00:00.000'.
Quindi, dire "query eseguite sul campo [Data_Documento] non distinguono
tra valore NULL e ''" � una bestemmia.
Il valore '' su una data significa '1970-01-01 00:00.000'.
Se invece parliamo di campi stringa (es. char e varchar), il valore ''
ha senso e significa esattamente "stringa vuota".
Per�, la clausola "where ([campo_stringa] is not null ) OR
([campo_stringa] <> '')" � giusto che escluda i NULL, perch� i NULL non
soddisfano ne il primo confronto (is not null) ne il secondo (<> '').
--
David Martin
Lorenzo Benaglia
> Come già indicato in un altro post, se in una data tu inserisci il
> valore '', SQL Server memorizza la sua data iniziale '1970-01-01
> 00:00.000'.
1970?!
SELECT CAST('' AS datetime)
/* Output:
-----------------------
1900-01-01 00:00:00.000
(1 row(s) affected)
*/
Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo
http://social.microsoft.com/Forums/it-IT/sqlserverit
David Martin
> "David Martin" wrote:
>> Come già indicato in un altro post, se in una data tu inserisci il
>> valore '', SQL Server memorizza la sua data iniziale '1970-01-01
>> 00:00.000'.
>
> 1970?!
Porcaccia miseria, mi hai subito sgamato :-)
La colpa non è mia, è di mysql che ha come "data di inizio" (passatemi
il termine) il 01-01-1970 :-P
--
David Martin
Pablo
> La colpa non è mia, è di mysql che ha come "data di inizio" (passatemi
> il termine) il 01-01-1970 :-P
Non è MySQL, è "Unix time" (o "Unix epoch"), usato in buona parte dei
linguaggi di programmazione, conseguentemente anche in molti db.
Se non ricordo male però l'SQL ha come "data zero" il "01/01/1900".