Newsgroup: it.comp.appl.access
Titolo: Funzione IIf in una query che storpia i numeri

Buona giornata a tutti.
Vorrei capire il perché di questo comportamento. Parto da una tabella
(MySQL collegata tramite ODBC) con tre campi contenenti valori reali
con al massimo tre decimali (quello che riporto è il contenuto come si
può vedere sia aprendo la tabella in Access sia con phpMySql):
Campo1 Campo2 Campo3
1153 1374,35 1434,7
196,152 233,808 244,076
Questi campi devono essere stampati in un report in base a certe
condizioni, per cui tramite una query li pre-processo. L'espressione
che uso è "campo: IIf(<condizione>;[tabella].[CampoX];0)".
Il risultato però è che i valori reali, quando la condizione è
verificata, vengono storpiati in questo modo:
1153 1374,34997558594 1434,69995117188
196,151992797852 233,807998657227 244,07600402832
Nemmeno col round([tabella].[campo];3) sono riuscito ad ottenere
qualcosa. Questi numeri vengono sommati e alla fine generano dei
risultati non corretti per via di queste storpiature.
Qualcuno sa spiegarmi il motivo di questoi comportamento? Come
rimediare?
Grazie in anticipo.
Alessandro

 ha scritto nel messaggio 
news:4b6018fb-ad5e-4977...@z19g2000vbz.googlegroups.com...
Buona giornata a tutti.
Vorrei capire il perch� di questo comportamento. Parto da una tabella
(MySQL collegata tramite ODBC) con tre campi contenenti valori reali
con al massimo tre decimali (quello che riporto � il contenuto come si
pu� vedere sia aprendo la tabella in Access sia con phpMySql):
Campo1 Campo2 Campo3
1153 1374,35 1434,7
196,152 233,808 244,076
Questi campi devono essere stampati in un report in base a certe
condizioni, per cui tramite una query li pre-processo. L'espressione
che uso � "campo: IIf(<condizione>;[tabella].[CampoX];0)".
Il risultato per� � che i valori reali, quando la condizione �
verificata, vengono storpiati in questo modo:
1153 1374,34997558594 1434,69995117188
196,151992797852 233,807998657227 244,07600402832
Nemmeno col round([tabella].[campo];3) sono riuscito ad ottenere
qualcosa. Questi numeri vengono sommati e alla fine generano dei
risultati non corretti per via di queste storpiature.
Qualcuno sa spiegarmi il motivo di questoi comportamento? Come
rimediare?
Grazie in anticipo.
Alessandro
Sono campi Double o Single e non vanno utilizzati in contabilit�
Piuttosto usare i Decimal con numero decimali fissi.
Potresti temporaneamente risolvere il problema formattando il campi nel 
report impostando il numero dei decimali a 2 per esempio.
Daniele 

 Daniele
Infatti nel report uso dei campi a formato fisso con due decimali. Il
problema è che in alcuni casi l'arrotondamento non è prevedibile. Ad
esempio:
303.855 (MySQL) => 303.855010986328 (query) => 303.86 (report)
157.745 (MySQL) => 157.744995117188 (query) => 157.74 (report)
A mio parere il primo arrotondamento non è coerente col secondo.
A parte il consiglio di usare il formato decimal, che in questo
momento mi è impraticabile, non si spiega perché Access introduca
tutti questi decimali senza motivo!

 Daniele
Infatti nel report ho usato un formato fisso con due decimali. Però
gli arrotondamenti non sono coerenti. Faccio due esempi:
157.745 (MySQL) => 157.744995117188 (query) => 157.74 (report)
303.855 (MySQL) => 303.855010986328 (query) => 303.86 (report)
I due numeri dovrebbero essere o 157.74 e 303.85 oppure 157.75 e
303.86, ma non 157.74 e 303.86!
A parte usare il formato decimal, che in questo momento è per me
impraticabile, vorrei capire perché Access introduce tutti quei
decimali che nella tabella originale non ci sono!

Scusate il doppio post...

 Daniele
Infatti nel report uso dei campi a formato fisso con due decimali. Il
problema � che in alcuni casi l'arrotondamento non � prevedibile. Ad
esempio:
303.855 (MySQL) => 303.855010986328 (query) => 303.86 (report)
157.745 (MySQL) => 157.744995117188 (query) => 157.74 (report)
A mio parere il primo arrotondamento non � coerente col secondo.
A parte il consiglio di usare il formato decimal, che in questo
momento mi � impraticabile, non si spiega perch� Access introduca
tutti questi decimali senza motivo!
Un'esperienza del genere mi � capitata con altri provider. Access, non 
avendo uno "schema" dei dati restituiti fa una conversione implicita con 
risultati imprevedibili.
A qutesto punto puoi decidere di confezionare direttamente le interrogazioni 
mysql con Decimal(m,d) o meglio Round(N, 2)
Ciao 

 Ciao
I dati li pesco dalla tabella collegata mediante ODBC. Non saprei come
"confezionare" questi dati (se potessi scrivere la query come faccio
in PHP sarebbe MOLTO più semplice); inoltre il round(;2) dentro IIF
non funziona (mi becco sempre ancora tutti i decimali, funziona solo
se non uso argomenti ma a questo punto resto con un intero...).

 Ciao
I dati li pesco dalla tabella collegata mediante ODBC. Non saprei come
"confezionare" questi dati (se potessi scrivere la query come faccio
in PHP sarebbe MOLTO pi� semplice); inoltre il round(;2) dentro IIF
non funziona (mi becco sempre ancora tutti i decimali, funziona solo
se non uso argomenti ma a questo punto resto con un intero...).
Trattando di ODBC invece di collegare la tabella creati uno statement query 
passthrough del tipo
SELECT Round(Campo, 2) From mysql.tabella
o qualsiasi altro statement ritieni opportuno in nativo MySql.
Ciao 

"OneEDP" <OneEDP@antispam> ha scritto nel messaggio 
news:4a167ff0$0$47542$4faf...@reader1.news.tin.it...

Con tale tecnica aumenti considerevolmente le prestazioni nel caso di 
interrogaziono leggermente pi� complesse o . Ti sconsiglio di collegare 
tabelle ODBC perch� Jet produce overhead sul server in modo  preoccupante se 
non si persta la dovuta attenzione. Ad esempio se effettui una join tra due 
tabelle collegate vedrai che strazio.
Ciao.

 303.86, ma non 157.74 e 303.86!
why not?!
157.744995117188 se la parte dal 3' dec in poi e' minore di 5 --> 157.74
303.855010986328 se la parte dal 3' dec in poi e' maggiore di 5 --> 303.86
arrotondamento pressoche' perfetto!

 Ciao.
Mah... ho provato a creare una query pass-through con la sintassi
MySQL (quindi "IF" al posto di "IIF" etc) ma il risultato non cambia:
SELECT IF(TRUE,campoX,0) AS campo_if, campoX AS campo FROM tabella;
campo_if campo
2,1612031459808 2,1612
583,59246826172 583,592
68,156692504883 68,1567
etc
E' normale?

 arrotondamento pressoche' perfetto!
L'arrotondamento è perfetto, certo, ma se consideri che il decimale
dal 3^ in poi non esiste nella tabella originale... Access può
arrotondare in modo perfetto, ma se lo fa su numeri che si inventa
allora capirai il mio disappunto.

 E' normale?
OK, ho riportato la stessa query in phpMyAdmin e il risultato è lo
stesso... credo che questo thread possa essere chiuso in quanto non
sembra essere un problema di Access.
Grazie cmq per gli spunti.

 allora capirai il mio disappunto.
Esiste e come. Se i valori, ad es, derivano da un calcolo e sono messi 
in un campo single o double hanno un certo numero di decimali. Tali 
decimali puoi "non vederli"  perche' la formattazione che richiedi 
limita il numero di decimali visibili. Quello di cui hai bisogno, a 
quanto  vedo, e' una istruzione di "floor", cioe' arrotondamento sempre 
verso il basso  (quindi non "round" ma "troncamento")
--
ac

 E' normale?
OK, ho riportato la stessa query in phpMyAdmin e il risultato � lo
stesso... credo che questo thread possa essere chiuso in quanto non
sembra essere un problema di Access.
Grazie cmq per gli spunti.
Non hai fatto la prova che ti dicevo.
Decimal tronca i decimali
Round arrotonda
ma la devi inserire nello statement MySql
Se campox lo restituisci cos� come � no hai risolto
Questa � la prova. Prova anche truncate (la funzione decimal pare non 
esista)
SELECT Round(IF(TRUE,campoX,0), 2) AS campo_if, Truncate(campoX, 2) AS campo 
FROM tabella
Allora Access si comporter� bene.-
Se hai ancora problemi allora usa la funzione Cast di MySql
Fammi sapere.
Daniele

 Daniele
Allora, il costrutto round(if(true,x,0),2) e truncate(x,2) funzionano,
con le attese differenze: ad es. se il dato originale è 68,1567, round
(if()) produce 68,16 mentre truncate() produce 68,15.
Tutto sommato sto rivalutando l'idea di usare decimal(x,y) al posto di
float per la tabella MySQL.
Grazie dei suggerimenti.