Newsgroup: it.comp.appl.access
Titolo: Valido se= null

Buona giornata a tutti.
Ho impostato, in una maschera, nel campo PREZZO nel formato Valido se= null.
Il problema che riscontro è che nell'inserire il nuovo record il campo 
effettivamente rimane vuoto ma se vado a consultare i record precedenti il 
campo prezzo si è trasformato in 0.00?.
Siccome i prezzi li inserisco anche in un secondo tempo, capirete che vorrei 
inserire io il valore 0.00? solo ed esclusivamente se il prezzo è realmente 
questo!
Qual'è il formato corretto del campo che mi occorre?
Grazie.
-- 
Giorgia Vitale
VITALE TRASPORTI
Via Torino, 173
10099 SAN MAURO 
T.SE
Tel.: 
+39 011.8220542
 
+39 011.8017194
Fax: 
+39 011.8220970

 Grazie.
Se imposti Null in "Valido se" non ti lascerà più inserire nessun prezzo.
Verifica piuttosto che non ci sia uno zero in "Valore predefinito", sia
nella maschera che soprattutto nella tabella.
Se vuoi fare dei controlli più articolati ed eventualmente dare un
messaggio all'utente ti consiglio di usare l'evento Before update (Prima
di aggiornare) della maschera. Trovi esempi e consigli sui post vecchi, se
ne è parlato spesso.
Ciao.
-Marco-
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Ciao.
-- 
Sergio MAZZA 


Intanto chiedo scusa perchè ho scritto male: il valore che imposto a null è 
il Valore predefinito e non il Valido se.....
Comunque Sergio mi hai capito, ti ringrazio.
Però non credo faccia al caso mio neanche questa soluzione che mi hai 
proposto e ti spiego perchè:
se anche riuscissi (perchè non sono così esperta e dovrei ancora capire 
farlo) a impostare il formato di visualizzazione che nasconda gli zeri, nel 
caso sia io a inserire il valore 0,00? nel caso volessi omaggiare di un 
servizio un cliente, anch'esso verrebbe nascosto....
Chissà se riuscirai a decifrare anche questo mio dilemma....
Grazie,
Giorgia 

 - Mostra testo citato -
Ciao Giorgia,
un modo semplice per nascondere lo 0 inserito su "Valore predefinito"
della tabella, è quello di mettere su "Valore predefinito" della
maschera le due virgolette ""
In questo modo un nuovo record avrà la casella di testo vuota
fintantochè la stessa casella di testo non verrà valorizzata anche
senza inserirci nulla (ad esempio inserendo i dati ad un'altra casella
di testo appartenente allo stesso record).
Poi, se proprio non vuoi vedere gli zero da nessuna parte, basta
andare sulla Formattazione condizionale della maschera o del report
mettendo la condizione che se il valore della casella di testo in
questione è = 0 il colore del carattere deve essere uguale al colore
di sfondo.
Ciao vladimiro.

 Giorgia
Non c'è nessun dilemma, ma solo una pianificazione migliore della banca dati 
(tabelle) con una struttura (tipologia di campi) coerente con i dati da 
contenere.
(ripeto per come la vedo io) Se hai dei campi numerici, è naturale che 
l'assenza di valore non è il Null ma lo zero; quindi i campi numerici 
dovrebbero avere come valore predefintito lo zero.
Poi tutti i giochi per la visualizzazione si fanno sulle 
maschere/report/query; un esempio di formattazione che visualizza Null 
invece dello zero potrebbe essere (preso dall'help in linea):
#,##0.00;(#,##0.00)[Red];"Null";"Null"
http://msdn.microsoft.com/en-us/library/aa195899(office.11).aspx
Ciao.
-- 
Sergio MAZZA 

Sergio MAZZA ha scritto:



Da come ho interpretato io la domanda non è un problema di visualizzazione.
Penso che lei voglia la possibilità di distinguere i prezzi in cui
l'operatore ha volontariamente inserito uno zero dai prezzi in cui non è
mai stato inserito alcun valore.


 -Marco-
"...mai stato inserito alcun valore..."; che significa? Che si aggiunge una 
variabile temporale? Ossia: "...da quanto tempo quell'articolo ha quel 
prezzo?".
Ma qualsiasi sia la domanda o l'esigenza, rimane il fatto che in un campo 
numerico non conviene utilizzare il Null; meno che mai per "distinguere" dei 
dati quando ci sono altri "mezzi"...
Ciao.
-- 
Sergio MAZZA 

Sergio MAZZA ha scritto:


In un nuovo record di una tabella prodotti:
1. compili la descrizione ma non il prezzo
2. compili la descrizione e inserisci prezzo zero
3. compili la descrizione e inserisci prezzo diverso zero
Lasciando come valore predefinito Null per il campo prezzo nella struttura
della tabella effettivamente si riesce a distinguere i record in cui
l'operatore ha inserito volontariamente lo zero (caso 2.) da quelli in cui
ha inserito solo gli altri dati e non ha mai toccato la casella prezzo
quindi il campo rimane Null (caso 1.).
Come alternativa si potrebbe usare un flag Si/No per marcare i prodotti
volutamente "gratuiti" di cui al caso 2.


 -Marco-
Ciao.
-- 
Sergio MAZZA 

 Ne vale la pena? Boh!
si se devi fare una media e di certi "articoli" ancora non ne conosci il 
prezzo. I calcoli fatti su un valore "null" in genere sono molto piu' 
coerenti di calcoli fatti su valori che dovevano essere null e non lo sono.
Azzerare un null non e' un gran problema ricavare da uno zero 
l'eventuale null, questo mi sembra un grosso problema, molto "grosso"
   ;<))))))))))))))))))))))))
--
ac

 ac
Ciao.
-- 
Sergio MAZZA 

 dovrebbero avere come valore predefintito lo zero.
Sergio perdonami ma questo è un grave errore concettuale e metodologico. Un
valore nullo _NON_E'_ un valore di un campo, ma uno _STATO_
Lo zero invece è un valore. Fra l'altro lo zero è anche not null ... ;-)
Ciao, Sandro
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 dati quando ci sono altri "mezzi"...
No Sergio, niente affatto. Un conto sono i _dati_ un altro sono i
_controlli_
Regola fondamentale dell'ingegneria del software, mai usare i dati a mo' di
controlli, o, viceversa. Credimi, se il paradigma relazionale prevede i null
un motivo ci sarà ...


 Ciao, Sandro
Ciao.
-- 
Sergio MAZZA 

 Ciao, Sandro
Sandro; se vogliamo tenere il discorso parlando in "programmatichese" hai 
ragione, e aggiungo che ne ero cosciente.
Il problema in questo caso, ripeto sempre secondo me, non è se il Null è un 
valore o uno stato; il problema è: "capirà l'operatore che non deve inserire 
lo zero altrimenti si taglia le palle? E capirà, sempre l'operatore che 
dovrà ricercare gli articoli (o i dati) che hanno Null, per inserire lo 
zero?".
Detto in parole povere; per chi lavora servono informazioni chiare non 
"sottigliezze" o artifici che può capire solo chi ha sviluppato 
l'applicazione...
Ciao.
-- 
Sergio MAZZA 

 zero?".
Senti su questo ti quoto in pieno ed incondizionatamente, e ti leggo da
tanto di quel tempo che non prendevo minimamente in conto che non sapessi
cos'è un valore nullo ... Ho solo fatto una precisazione, visto che, mi devi
credere, c'è un sacco di gente che esce dagli studi convinta che un null sia
un valore, e poi passa settimane intere a comprendere perchè il test fatto
con l'uguale (campo=null) non funziona ... ;)
Per questo ho fatto la precisazione valore e stato.
Sono daccordo con chi ha proposto l'uso di un flag apposito (un dato
appunto), anziche testare lo stato null del campo prezzo (che è un controllo
che verrebbe usato pericolosamente con un dato esplicito).
Certo è che se il prezzo non esiste non andrebbe neanche interpellato nelle
funzioni statistiche, come giustamente obiettava qualcuno. Ma con un flag il
problema non si porrebbe, perchè ci sarebbe la condizione di selezione
esplicita nella parte WHERE della query di aggregazione ...
Ciao, Sandro.


 esplicita nella parte WHERE della query di aggregazione ...
Ma andiamo Sandro, per quale motivo qualcuno si doveva inventare il 
"null" se poi per gestirlo hai bisogno di in flag di controllo?
Parlando di "operatori". Io avro' dei clienti/utenti strani, 
generalmente sono sempre piu' "clever" del sottoscritto!
--
ac

 Ciao, Sandro
Si siamo d'accordo sul cosa è o non è il Null; ma all'atto pratico, di chi 
deve utilizzare il programma (non di chi lo scrive) ossia l'operatore, 
queste spiegazioni non hanno senso.
Probabilmente la mia affermazione deriva da 10 anni di data-entry; dove 
persone che sviluppavano applicativi senza avere un occhio rivolto 
all'utilizzatore, partorivano (e lo fanno tutt'ora) passaggi così intricati 
che "giochi senza frontiere" era una "scopetta" al bar!
E tu prova a farglielo capire che (per esempio) un controllo di validità su 
ogni campo è una perdita di tempo (del mio tempo non del suo) quando puoi 
farlo alla fine della pagina d'inserimento dati, magari producendo un output 
leggibile con la tipologia dell'errore!!
Così per me è inutile inserire informazioni monche; un articolo in vendita 
se non ha il prezzo che ci sta a fare? Diverso è il discorso se si parlava 
di Anagrafica Articoli; allora si che ha senso l'esistenza di tutti gli 
articoli ma in quella tabella (Anagrafica Articoli) non mi sarei certo 
preoccupato di inserire i prezzi...
Ciao.
-- 
Sergio MAZZA 

 Ciao, Sandro.
Ciao.
-- 
Sergio MAZZA 

Sergio MAZZA ha scritto:

Sergio dixit! senza se e senza ma!
Parafrasando un celebre detto
"ne ammazza piu' il valido se (e il Null) della spada"
--
ac

 ac
Parlando di cose serie; ci vieni alla sagra dell'amatriciana?
Ciao.
-- 
Sergio MAZZA 

Sergio MAZZA ha scritto:

Parliamone. Dove, come, quando! Il perche' non serve, "la matriciana" 
spiega gia' tutto, e non e' decisamente un "null" e non ha bisogno di 
"valido se", sperando che non ci mettano la cipolla! ;<)))))
--
ac

 "valido se", sperando che non ci mettano la cipolla! ;<)))))
Oggi dalle 17:00 e domani tutta la giornata; io vado oggi, mi muovo alle 
15:00...
Ti mando il cellulare, se per caso lo hai cancellato!


In alcuni casi appunto.
Cioè se si devono inserire dei prodotti che hanno dei prezzi costanti almeno 
per un certo tempo...
Ma io gestisco trasporti e le mie distinte sono un elenco di viaggi i cui 
costi sono molto variabili.
Per di più i clienti, che dettano i prezzi, spesso non mi mandano i prezzi 
di viaggio in viaggio quindi a fine mese ho la necessità di creare una 
distinta provvisoria selezionando tutti i viaggi per i quali non mi è stato 
comunicato il prezzo, inviarla ai clienti, per poi riceverla compilata e 
finalmente andare a inserire i prezzi nelle maschere.
Se però creo una query filtrando il valor 0.00?, potrei fare una figuraccia 
col cliente se avevamo già concordato un servizio omaggio per il quale avevo 
inserito IO il valore 0.00?....
ma la query non distingue il valore 0.00? inserito da me e quello che è 
comparso automaticamente....
Spero che così capirete meglio la mia necessità che per alcuni sembra così 
astrusa.....
Buona l'amatriciana??.....:-))
Giorgia 

 Giorgia
Non voglio certo sconvolgerti il lavoro fino a qui fatto, ma sono sempre più 
convinto che conviene separare le informazioni (diciamo) anagrafiche del 
prodotto e lo storico dei prezzi.
Per storico intendo una tabella del genere:
[tabProdottiPrezzi]
- idProdotto, intero lungo, duplicati ammessi;
- prezzo, numerico, (valore default: 0);
- dataPrezzo, (formato: data), (valore default: date);
Creando una tabella dei prezzi, gestisci anche i prodotti che non hanno mai 
avuto nessun prezzo (non esiste nessun record in relazione con la tabella 
[tabProdottiPrezzi]); e se inserisci un prezzo hai anche la data automatica 
della creazione del record(prezzo).
Per avere sempre l'ultimo prezzo, basta che leggi, per ogni record 
(prodotto), il Max(dataPrezzo)...
Ciao.
-- 
Sergio MAZZA 

 Ammazzala! E pure al dente; peccato che era imbastardita col pomodoro!!
Questo e' un argomento "scottante". Neanche ad Amatrice pare si siano 
messi d'accordo, insomma e' ancora un po' "gricia"!  ;<)
--
ac


Eh ma io č proprio questo che non posso avere, uno storico dei prezzi!
E' un settore un po' del menga il mio e ogni viaggio ha una discussione sul 
prezzo a sč, in parole povere discuto il prezzo ogni volta che mi affidano 
un servizio...o addirittura devo aspettare che il cliente me lo comunichi 
anche a fine mese ecco perchč non voglio che venga in automatico lo 0.00? ma 
che rimanga Null se il prezzo dev'essere anora comunicato.
Capita un po' meglio la mia esigenza ora?
Giorgia

 messi d'accordo, insomma e' ancora un po' "gricia"!  ;<)
Eh! Eh!
Ma t'assicuro che lo sanno perché tra gli stand di olive ascolane e fritti 
misti (bboni!), c'era un piccolo stand con a fianco un cartello: "Qui nacque 
la matriciana".
Sai cosa c'era? Un fuoco, delle pelli di pecora, pecorino, pasta, guanciale 
(non pancetta!).. E basta!
L'amatriciana era il cibo dei pastori e ti ci voglio a portare il pomodoro 
nei pascoli!
Quello che non sapevo e mi hanno riferito è che il pomodoro ce l'hanno 
infilato i napoletani; e te pareva! Ce lo infilato dappertutto!!!


 Giorgia
No; ma è un mio limite...
Ciao.
-- 
Sergio MAZZA 

 Sergio MAZZA
Tra l'altro i Null, se non ricordo male, non contribuiscono alle
relazioni fra tabelle nelle query; nel senso che
Tabella1
Id1 Anno Numero SubNumero
Tabella2
Id2 Anno Numero SubNumero
se in SubNumero lascio i Null perché non ho impostato 0 come valore
predefinito
la relazione  Anno, Numero, SubNumero -> Anno,Numero, SubNumero non
collegherà i record che in SubNumero hanno il Null (anche se in i
valori in Anno e Numero sono uguali )
Dico male ?
Propongo una soluzione:
Valore predefinito -1 (significa nessun prezzo inserito)
Nella maschera il controllo del prezzo (associato al campo es: Prezzo)
è nascosto
C'è un controllo visibile non associato denominato es. tbPrezzo
Nell'evento SuCorrente si chiama una sub:
sub ImpostaPrezzo(strModo as string)
if strModo = "FieldToControl" then
  if me.Prezzo = -1 then
       me.tbPrezzo = "<prezzo non inserito>"   'o qualcosa del genere
  else
     me.tbprezzo = me.prezzo
   end if
else
  me.prezzo = me.tbprezzo  'il controllo me.prezzo è non visibile e
associato al campo della tabella denominato Prezzo
end if
end sub
un mini pulsantino accanto al controllo me.tbprezzo  "Elimina prezzo"
che imposta il valore di me.prezzo = -1 (cioè prezzo eliminato, non
inserito) e chiama la sub di cui prima con parametro "FieldToControl"
nell'evento afterupdate di tbprezzo si chiama di nuovo la sub con
parametro "ControlToField"
naturalmente occorre gestire la presenza dei valori negativi tutte le
volte che si eseguono del calcoli o delle query che interessino il
prezzo, ma questo dovrebbe essere fatto sempre anche nel caso di un
flag o del valore Null
E' pensata male ?
AleC

 - Mostra testo citato -
Concludendo:
Se il prezzo non è inserito deliberatamente nel controllo della
maschera apparirà la scritta <prezzo non inserito> o N/A o qualsiasi
altra cosa significativa del concetto.
Se il prezzo è stato deliberatamente inserito (anche se 0) apparirà 0
o il prezzo positivo.
Se si deve togliere il prezzo e ripristinare la situazione di partenza
con prezzo non inserito il pulsante imposterà il valore del campo (nel
controllo non visibile associato) a -1 e la sub farà apparire
nuovamente la dicitura <prezzo non inserito>
Nel campo Prezzo della tabella avremo un -1 quando non si è mai
inserito un prezzo (valore predefinito) altrimenti il valore inserito
(foss'anche 0)
Avevo dimenticato di fare la chiusura.
AleC

 ha scritto nel messaggio 
news:3074178b-aa81-4365...@a1g2000hsb.googlegroups.com...

Concludendo:



AleC
[risposta]
AleC, questa è la dimostrazione che di modi per gestire un problema ce ne 
sono molti; io facevo più un problema di analisi... Ma mi rendo conto che 
alcune volte esagero...
Ciao.
-- 
Sergio MAZZA 

 ha scritto nel messaggionews:3074178b-aa81-4365...@a1g2000hsb.googlegroups.com...

La tua analisi mi trova d'accordo, infatti ho fatto notare che il
valore Null non è significativo nelle relazioni fra tabelle in una
query.