Newsgroup: it.comp.lang.visual-basic
Titolo: Re: Query assurda!!!! Perchè qualche volta non va?

 and da*100<=220 and a*100>=220 and cod_cliente="RT"
Non hai specificato:
- Che dbms usi
- Di che tipo sono DA e A
Comunque, se scrivi
da*100.0<=220.0 and a*100.0>=220
funziona?
Alberto
-- 
"C'č un Calvelli dentro ognuno di noi" (cit.) 

Perchč questa query
select * from qryListino where  cod_tipo_ing="AV" and cod_lav="PF  " and 
da*100<=220 and a*100>=220 and cod_cliente="RT"
 Cosě non funziona mentre se i valori sono 219 0 221 funziona?
Premesso che se tolgo la moltiolica *100 e passo 2,2 funge?
C'č un motivo o devo prenderlo come dogma?
Grazie Gab 

 Purtroppo NO
Strano.
Verifica il tipo dei campi DA e A (se vengono da una query, posta la query 
d'origine.
Ciao
Alberto
-- 
"C'è un Calvelli dentro ognuno di noi" (cit.) 

 hai provato a mettere tra parentesi i valori che moltiplichi?
Cosi?
select * from qryListino where  cod_tipo_ing="AV" and cod_lav="PF  " and 
(da*100)<=220 and (a*100)>=220 and cod_cliente="RT"
No, non funziona! 

 ha scritto:

Aggiungo che non funziona con 2.20 e 4.40 per il resto va sempre! 


hai provato a mettere tra parentesi i valori che moltiplichi?
--
SCIRIO - 100% COMMERCIALE - 
http://scirio.altervista.org

 Alberto 

 Alberto 

 Ciao 


Ovviamente funziona.
Grazie Gab
Dici che posso lasciarlo così (decimale a due pos) il campo?

 Aggiungo che non funziona con 2.20 e 4.40 per il resto va sempre!
Prova a vedere così:
select *, da*100, a*100 from qryListino where  (cod_tipo_ing='AV') and 
(cod_lav='PF  ') and (cod_cliente='RT')
e se non noti niente di strano poi prova così
select * from qryListino where  (cod_tipo_ing='AV') and (cod_lav='PF  ') and 
(cod_cliente='RT')
and (da*100<=220)
e così
select * from qryListino where  (cod_tipo_ing='AV') and (cod_lav='PF  ') and 
(cod_cliente='RT')
and (a*100>=220)
Direttamente da Access!
Ciao 

 Dici che posso lasciarlo cosě (decimale a due pos) il campo?
Da un punto di vista concettuale, se la precisione con cui gestite il 
diametro č al centesimo, č giusto lasciarlo cosě.
Magari mettilo a 3 posizioni, supponiamo che un domani abbiate un calibro 
migliore e iniziate ad archiviare anche valori piů precisi.
L'importante, comunque, non č 'quante posizioni', ma che siano fisse.
Tu prima avevi un tipo a virgola mobile, che va bene per cose scientifiche, 
non certo per valori discreti precisi.
Le uniche problematiche potresti averle se il valore del diametro viene 
utilizzato per calcoli scientifici (che so, per stabilire la conduttanza del 
cavo bla bla bla...). Se hai delle query che lavorano in questo modo, 
sarebbe bene iniziare l'utilizzo del campo con un cast esplicito verso un 
tipo a maggiore precisione (fino anche al virgola mobile, eventualmente).
Se invece i tuoi campi sono importi e misure usate solo per archiviazione, 
fatturazione, ecc..., i tipi a virgola mobile potresti bandirli in tutto il 
db.
Ciao
Alberto
-- 
"C'č un Calvelli dentro ognuno di noi" (cit.) 

 Numerico a precisione doppia con posizione fissa a due decimali
Con una risposta cosě, mi diventi simpatico.
Spiegami un po', che cosa ci fai con un "Numerico a precisione doppia con 
posizione fissa a due decimali"?
Cioč, a parte l'aspetto Sql, *cosa* rappresentano i campi A e DA?
Alberto
-- 
"C'č un Calvelli dentro ognuno di noi" (cit.) 

 moltiplicando per 1000 e non per 100
Beh, funziona per 2.2, ma magari non va per 3.3 (è un esempio).
Non mi sembra la soluzione.
Ti propongo una prova.
Fai una copia del tuo db.
Prendi la tabella da dove partono gli importi (cioè, da dove vengono pescati 
i cosi che diventano DA e A), e converti la colonna dell'importo in tipo 
"Valuta" o in tipo "Numerico Decimale a due posizioni".
Poi fai rigirare le query, e dimmi se cambia qualcosa.
Ciao
Alberto
-- 
"C'è un Calvelli dentro ognuno di noi" (cit.) 

 L'operazione campo A sia maggiore/uguale di 220
Campo A per 100 ...logicamente...mi è rimasto nella tastiera!
altra svista non ho chiuso le parentesi
 and
( (da*100) <=220) )
and
( (a*100) >=220) )
approfitto per farti notare che così facendo PRIMA faccio la moltiplicazione
SICURAMENTE
e poi eseguo il test!

 Ciao
Ti confermo che i valori sono tutti giusti!
2.20 viene visualizzato 220 etc
Ciao Gab
PS ora prova la tua soluzione perchè come mi suggerisce anche Albe la mia 
"Alpinata" non è sicura

 Allora è per questo che con *1000 funziona!
Non è detto.


 e poi eseguo il test!
Il problema non č che non funziona la query, č che non funziona solo con 220 
e 440. Con tutti gli altri numeri che il cliente in 4 anni ha usato č sempre 
andata!!! 


DA e A però si riferiscono ai diametri! Provo comunque mettendo decimale a 
due posizioni
Ciao 

 Va beh, il problema č tuo, se limi sulle risposte non so che dirti.
Basterebbe legger bene le domande ;-). Me ne era scappata un pezzo. Per 
dovere di cronaca Access 2000
Scusa.
 Gab 

 ????????
Certo che esiste!!!!
Sono stato un po' maleducato con Rafunk perchč non gli ho risposto ma la via 
del "fammelo scrivere ben benino" l'avevo giŕ seguita ma non mi aveva 
portato da nessuna parte.
Nei messaggi sopra il motivo č emerso.
Grazie comunque.
Gab 

 <220
Vabbè tabliando corto, così riassumo anche il pensiero degli altri: è un 
problema di arrotondamento.
Capita usando i double.
Prova così e vedrai che si risolve (se ho fatto i conti giusti :P ):
select * from qryListino
where (cod_tipo_ing='AV') and (cod_lav='PF  ')
and (da*100-220<0.00001) and (a*100-220>0.00001) and (cod_cliente='RT')
Ciao 


Come ti diceva rafunk....siamo esseri umani non cavalli!
Io la riscrivo cosě
SELECT * FROM qryListino
 WHERE
(
(cod_tipo_ing="AV")
 and
(cod_lav="PF  ")
 and


 Ciao

 Alberto 

 ha scritto:

Così funziona per il 220 ma non per il 219 che è l'estremo del listino 
inferiore
Provo un po' a giocare con  i valori di arrotondamento.
Devo salire con i decimali "0.000000000001" o scendere "0.01"?
Grazie gab 

 ha scritto nel messaggio
news:d3e1lj$ie3$1...@domitilla.aioe.org...

Hai provato con qualche parentesi in piů?
select * from qryListino where (cod_tipo_ing="AV") and (cod_lav="PF  ") and
(da*100<=220) and (a*100>=220) and (cod_cliente="RT")
Bye
Raf

 Nei messaggi sopra il motivo è emerso.
Infatti ho visto l'ultimo post (18.21) in cui eravate sulla buona strada.
A parte che io avrei scritto (2.2 BETWEEN da AND a)... ma non so se avrebbe
funzionato!
Se ho ben capito il problema si manifesta nel caso "=" delle due disuguaglianze.
Teniamoci per buone le disuguaglianze strette (> e <) e interveniamo sul caso
"=", rendendolo un po' più elastico, meno sensibile agli errori di
arrotondamento, e modifichiamo così la query suggerita da Zanna:
select * from qryListino
where (cod_tipo_ing='AV') and (cod_lav='PF  ')
and ((da*100<220) OR (ABS(da*100-220)<0.00001)) and ((a*100>220) OR
(ABS(a*100-220)<0.00001)) and
(cod_cliente='RT')
Funziona?
Bye
Raf

 PS Adesso cerco anche di studiarla.
Gabriele, sinceramente...
Lascia perdere questa soluzione.
Il vero problema è che per valori a precisione fissa (come nel tuo caso) si 
devono usare campi a precisione fissa.
Punto e basta.
Correre dietro al problema con questi sistemi (che funzionano, certo, ma è 
un rimedio sintomatico, non alla radice) ti espone ad altri potenziali 
problemi.
Dicevamo ieri che un domani potresti avere necessità di un dettaglio 
migliore nella classificazione del diametro del prodotto, per cui potresti 
aver bisogno di archiviare come significativa le 5° cifra decimale. Beh, la 
query qui sopra ti andrebbe in palla, restituendoti dati sbagliati.
La soluzione è una ed una sola: converti i tipi a virgola mobile, che hai 
nel db, in tipi a virgola fissa (ad esempio il "Valuta" o, ancora meglio, il 
decimale con un numero di posizioni elevate, anche 10, se vuoi, ma *fisse*).
Il fatto che tu stia valutando queste opzioni 'pezza', mi fa supporre che tu 
non abbia ben compreso il perchè del problema, o, peggio, che tu non abbia 
voglia di risolverlo veramente ma solo di far funzionare alla svelta 
l'applicativo (che poi si fa prima a convertire un paio di colonne che a 
riscrivere le query...).



BINGO! Faccio un po' di prove ma direi che è perfetto. Grazie Mille
PS Adesso cerco anche di studiarla.
Grazie Gab 

 mettere mano al programma (ed in futuro cambiare il db in SQL)
Non mi interessa che tu scelga la 'mia' soluzione piuttosto che un'altra.
Mi preme che tu abbia ben compreso la differenza tra virgola mobile e 
virgola fissa.
Se l'hai capito, sei in grado di ponderare le scelte, e anche la 'pezza' 
potrebbe essere una scelta valida, perchè avrai soppesato pro e contro.
Ma se non hai ben chiaro il concetto, allora la 'pezza' è veramente una 
'pezza'.
Quando affronterai il passaggio a Sql-Server, tieni presente che quel dbms è 
estremamente rigido con la tipizzazione (un po' come C rispetto a VB), per 
cui certe cose *devono* essere chiare e fluenti.
Ciao e buon lavoro.


 ha scritto:

Sono assolutamente convinto delle tue affermazioni e la tua soluzione 
ritengo sia la più corretta. Non è una pezza che ovvia al problema, ma è la 
soluzione del problema. Siccome, come già ti scrivevo, devo mettere mano al 
programma (ed in futuro cambiare il db in SQL) uso questa come soluzione 
temporanea. Quando dovrò riscrivere il DB terrò sicuramente conto del tuo 
suggerimento. Facendo queste modifiche verifico bene l'incidenza della 
modifica al DB per mettere in pratica subito il consiglio. Sul mio db ha 
funzionato al volo (ovviamente)
Non prendere questo mia scelta ( di seguire il consiglio di Rafunk) come 
atto di supponenza. Io so di dover imparare sicuramente da tutti, ed alla 
fine della giornata di lavoro, sono contento di quanto ho fatto, ma molto di 
più di ogni cosa nuova che ho imparato. La soluzione di Rafunk certamente 
non va dimentica ne persa: Verrà il giorno in cui la 'pezza' sarà l'unica 
soluzione possibile. Perchè non studiarla per metabolizzarla?!
Comunque ringrazio te e tutti coloro che mi hanno aiutato.

 ha scritto:

Concetto arrivato!
Ciao Gab