Newsgroup: it.comp.appl.access
Titolo: comparazione tra due campi a precisione doppia

Mi e' capitato un problema che ho risolto a forza di tentativi ma
senza un fondamento logico apparente. Due campi numerici della stessa
tabella apparivano uguali ma il VBA li considerava diversi! Entrambi
erano definiti come campi numerici a precisione doppia con 3 cifre
decimali. Dopo diversi tentativi di variare le proprieta' dei campi,
il caso si e' risolto trasferendo uno dei due campi in una variabile a
precisione singola e quindi comparando la variabile con l'altro campo!
Mi sembra un rimedio assurdo. Qualcuno degli esperti di questo gruppo
ha un'idea della ragione del verificarsi di casi come questo e conosce
qualche soluzione piu' razionale? Grazie
Leonida 

decimali. Dopo diversi tentativi di variare le proprieta' dei campi,
non mi vorrei sbagliare, ma il numero di decimali č solo una proprietą
di visualizzazione.  voglio dire, un valore avrebbe potuto essere, fai
conto, 3,12736572 e l'altro 3,12744.  entrambi vengono *visualizzati*
come 3,127, ma sono ovviamente diversi.
dovresti quindi fare in modo di "eliminare" o arrotondare i decimali,
usando proprio delle variabili di appoggio.
ad esempio, se ti interessano tre decimali, io moltiplicherei i valori
per 10^3 (1000) e prenderei solo la parte intera.
--
non studio non lavoro non guardo la tv
non vado al cinema non faccio sport
----------------------------------------
il sito comune di it.comp.appl.access:
http://members.xoom.it/it_db_access

.......
Il ragionamento mi sembra plausibile, ti ringrazio, ma vorrei chiarire
meglio che cosa mi succede. Quando vado a vedere una tabella in cui ho
messo il campo numerico a doppia precisione, se ho definito 3 cifre
decimali, ne vedo 3 solo se ho impostato il formato a 'fisso',
'standard' o 'valuta'. Negli altri casi Access 97 se ne frega delle 3
cifre desiderate (in qualche caso non avrebbe senso avere 3 cifre,
come nel caso delle percentuali). 
Ma se fermo l'elaborazione al momento della comparazione io vedo
(nelle tipiche etichette gialle o nella finestra di debug), per
esempio, nel record di una tabella da esaminare, 8,24 (con solo 2
cifre decimali), nel record dell'altra tabella, diciamo, di controllo,
8,23999977111816. Nella variabile a precisione singola in cui
trasferisco questo valore mi ritrovo regolarmente 8,24.
Per fortuna ci pensa il sistema ad arrotondare. 
Ma la cosa piu' buffa e' che quel numero con 14 decimali era stato
calcolato poco prima in una variabile a precisione doppia, dove era
esattamente 8,24, e quindi memorizzato nel campo sempre definito a
precisione doppia, dove ha assunto l'altro aspetto a 14 cifre. Quando
provo a comparare questo campo con la variabile di origine (basta che
scrivo nella finestra di debug "?src_tab!campo1 = var") scopro che
sono ancora uguali, ma quando lo comparo con un altro campo a doppia
precisione che contiene 8,24 ed è considerato uguale alla variabile di
origine, il risultato e' 'diverso' (cioè l'uguaglianza e' falsa)! 
In base a queste ed altre esperienze io ritengo che ci sia una
disparita' di trattamento tra campi di tabelle e variabili, che si può
governare solo facendo un po' di... salti mortali :-)

 governare solo facendo un po' di... salti mortali :-)
Ciao,
per abitudine ho eliminato le variabili a precisione singola, proprio
perché, in passato, avevo avuto rogne in maniera apparentemente casuale
passando valori da precisione doppia a singola e viceversa.
--
Silvio


Silvio
Perfetto. E' quello che volevo fare anch'io, ma non è stato possibile!
Infatti il mio guaio capita passando da una variabile a precisione
doppia ad un campo a precisione doppia e viceversa. E mi salvo proprio
usando alla fine una variabile a precisione singola.
Non so se sono riuscito a spiegarmi, ma io assisto ad un caso di
questo genere: a=b, a=c, ma b<>c! E sono tutti e tre a precisione
doppia! a è una variabile, b e c sono due campi.
Leonida

 Leonida
Controlla la struttura della/e tabella/e con i 2 campi: deve esserci una
differenza che fa la differenza.
