Newsgroup: it.comp.appl.access
Titolo: Salve, chiedo lumi e/o patch per Access2K (1+1=1,999999...)

Come intuibile dall'oggetto ho un problemino con Access,
mi son fatto un mini "programmino", 2 tabelle, 1 query ed una maschera
per uso ufficio, un "programmino" abbastanza banale, ma evito così
di dover usare spesso la calcolatrice.
Il problem sorge quando voglio confrontare una somma di valori
immessi a mano col risultato sempre immesso a mano
Esempio, immetto a mano i valori A,B,C (inrealtà son 8 in tutto)
Mi serve una piccola funzioncina che mi verifichi se la somma
mi dia il risultato che ho scritto (C) ed al massimo mi visualizzi un
errore...
Il problema è che non so caxxo sia,
Se scrivo 1,00 + 2,20 = 3,40 a video ho in effetti i valori corretti,
ma NONOSTANTE abbia imposto precisione singola 2 decimali dopo la
virgola, se sblocco tutti i decimali (precisione doppia 15decimali)
vedo che sto figlio di p*****a mi mette dei decimali che vuole lui in fondo
es se scrivo 1, mi ritrovo in cella un valore pari a 1,00000000344556...
Ok che a video, l'errore è talmente irrisorio che non me ne frega un cavolo,
ma con sta fregatura non posso far funzioni banali, e volevo evitare di 
dover
fare una roba tipo X= ( intero (A x 100) ) / 100  specie di un valore che
immetto a mano...
Vi ringrazio di eventuali spiegazioni, link o consigli.
A.GiovanniB. AKA LEOrap IHMS-Bergamo ICQ {76678996}


Ciao e benvenuto,
Inserisci in un modulo questa funzione
Function fctRound(Optional varNr, Optional varPl As Integer = 2) As Double
   If IsMissing(varNr) Or Not IsNumeric(varNr) Then Exit Function
   fctRound = Fix("" & varNr * (10 ^ varPl) + Sgn(varNr) * 0.5) / (10 ^
varPl)
End Function
Poi le tue somme o moltiplicazioni saranno
C= fctround(A*B)
-- 
_ _
Ciao
MAssimiliano Amendola
Cisa1 - I° Conferenza Italiana per Sviluppatori Access Arezzo 4+5
Giugno 2005 Sono aperte le iscrizioni  Info:  
www.donkarl.com/it

 ha scritto nel messaggio 
news:3Dq9e.74668$zZ1.2...@twister1.libero.it...

Non so se ti risolve il problema ma, con Access, non usare MAI valori in 
precisione singola (Single), sempre doppia (Double)...
Ciao
Silvio 

 precisione singola (Single), sempre doppia (Double)...
Che gli risolva o meno il problema, la tua affermazione non è corretta.
In generale i floatings point sono "approssimativi": anche usando il formato
doppia precisione si possono verificare approssimazioni decimali nei
risultati dei calcoli: provare per credere.
I Single sono da evitare quando la logica gestionale non li richieda (campi
che andranno a contenere valori oltre il limite di
memorizzazione del precisione singola), oppure per semplice "antipatia"
personale.
Ma in ogni caso, sia chiaro, anche con i Double il problema degli errori
d'arrotondamento nei calcoli sarà latente.
Ci sono vari metodi per aggirare:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q210423
Personalmente consiglio l'utilizzo di CDec()
Ciao.

 C= fctround(A*B)
Tnk, proverň.
Grazie a tutti.
A.GiovanniB.
-- 
      LEOrap      IHMS-Bergamo      ICQ {76678996}

 quota un po quando rispondi.
ROTFL


 ROTFL
Perchè, glielo dite spesso? ;~)



Indubbiamente hai ragione su tutto! Sconsiglio i Single perché ritengo che 
gli errori si propaghino con una rapidità veramente inaccettabile. Non avevo 
mai preso in considerazione il tipo di dati Decimal ma sembra molto 
interessante...
Ciao
Silvio 

 molto interessante...
Infatti ho provato ad usarli in questo prg banale che ho fatto  (quello del 
post)
e finalmente sega i valori alla 2° cifra!
Impostato a:
- 18 di precisione (lo mette di default)
- 2 di decimali dopo la virgola
- 2 di decimali che voglio vedere.
E funziona... ora lo sbattimento sarà...
di convertire il "programmone" ;-/
Chissà che divertimento ^_^
Solo di tabelle, ne ho una 15ina piene di campi al limite del contenibile 
;°)
Lo so che per pacconi così grossi sarebbe meglio usare altri prg più 
profetional
e trasformarlo in un programam vero e proprio, ma siccome questo 
"programmino"
viene modificato/aggiornato/integrato giorno per giorno, non solo da me, in 
base
a ciò che serve, beh... mi conviene Access ^_^
Cmq vi ringrazio TUTTI della disponibilità!
Bye.



Guarda che usi male le foto e il db è gonfiato.
non riapro qui la polemica del programma professionale


 gli errori si propaghino con una rapidità veramente inaccettabile.
Beh, è chiaro che li hai sconsigliati per quel motivo ... e in effetti è una
filosofia non opinabile quella d'utilizzare solo il tipo di floating point
più "capiente".
Detto ciò, la velocità con cui si propagano gli errori di calcolo è un
parametro NON significativo: gli errori non devono proprio esistere!   :-)
Specialmente quando i risultati saranno poi archiviati in tabelle.
Come già dicevo, avendo l'accortezza d'applicare CDec() agli argomenti
floating point dei calcoli, i risultati saranno precisi: Single o Double che
siano.
Ciao.

 profetional
Il problema č un altro fratello: per pacconi cosě grossi sarebbe meglio
*imparare*   l'utilizzo di Access e relativo Visual Basic!
Ciao.

 ha scritto nel messaggio 
news:38K9e.57116$IN.10...@twister2.libero.it...

Beh... il mio programmino č composto da
~90tabelle
~80query
~450maschere (ognuna con anche 2-3 pagine di codice)
~200macro
Beh, anche comprimando qua e la, direi che non si puů farlo dimagrire ;-)


 non riapro qui la polemica del programma professionale
Si, si, immagino che ne avrete parlato.


 Si, si, immagino che ne avrete parlato.
-- 


 ;-)
-- 


 Beh, anche comprimando qua e la, direi che non si puù farlo dimagrire ;-)
Eh, eh, eh...
Con tutto il rispetto: un tizio che ignora come trattare i floating point
nei calcoli, non è proprio nelle condizioni di stabilire cosa sia o NON sia
"professionale" e stabilire se un'applicazione sia abbastanza "magra"   :-)
Ma è pur vero che nelle aree pubbliche chiunque abbia una tastiera sottomano
può picchiarci sopra quello che gli pare...
In rapporto alle cifre che hai citato, farei alcune considerazioni
aggiuntive:
1.
le tabelle, 90 o 900 che siano, saranno "stoccate" in un .mdb a parte o su
un Server SQL, quindi esulano dalla cura "dimagrante" e da qualunque
considerazione inerenti le dimensioni dell'applicazione Front-End.
A meno che tu non le abbia lasciate nel FE  (PORC...), in tal caso vanno
tolte!
2.
Le query possono essere costruite dinamicamente nei moduli di codice VBA,
invece che salvate nel FE.
I piani di compilazione delle Query "salvate" occupano spazio su disco e
producono benefici in termini di prestazioni, oggigiorno, assolutamente
risibili.
A parte questo la costruzione dinamica di stringhe SQL attraverso Visual
Basic consente un'ottima ri-leggibilità e un controllo totale della
situazione quando si debbano realizzare selezioni complesse dipendenti da
una moltitudine di parametri sulle Forms.
2.
450 maschere, OGNUNA con modulo di codice indicano metodi di sviluppo
che non valorizzano sufficientemente la "riusabilità del codice".
Peraltro una Form/report priva di modulo di codice alloca assai meno spazio
su disco.
4.
Evita le Macro: non servono a nulla, occupano spazio e riducono notevolmente
la leggibilità dei programmi.
5.
Non inglobare immagini pesanti nelle applicazioni e se lo fai utilizza
esclusivamente
il formato .bmp;  a progetto terminato reimporta tutto in un nuovo .mdb
e crea il relativo file .MDE.
I principali applicativi sviluppati nell'ente in cui lavoro (non solo da me
ovviamente) hanno caratteristiche ** numerologiche **  simili alle cifre che
hai citato, con l'aggiunta di una buona scarica di Reports.
Eppure i relativi FE  .ADE  allocano non più di 25 MB!
Ciao.

 Che ti affidi alle macro apnche per aprire maschere?
Solo una 40ina, spesso uso codice.
D'altronde dev'esser "smanettato" anche da un paio di persone
che ci capiscono molto poco di programmazione, quindi non volendo
compilare millemilavolte un programma, access, pare abbastanza
"malleabile" ;-)


 Magari tutte jpg!?!
Si, JPG compresse
D'altronde mi servono, e lasciarle fuori dal DB mi rompe le @@,
mi piace viagiare con 1 solo file, mentre alcuni colleghi amici,
per un programma simile usano Approach...
A me di girare con una cartella con millemila files, mi rompe ;°)


 Eppure i relativi FE  .ADE  allocano non più di 25 MB!
Eh, ma ho sesigenze "particolari", conoscenze e tempo abbastanza limitate,
quindi... nel possibile tito avanti così ;°)
-- 
      LEOrap      IHMS-Bergamo      ICQ {76678996}
=========================================
        Ex F12 truccato, Ex Leonardo2½ tamarrizzato,
    ORA su Fz6 Fazer '04    
LEOra...@hotmail.com
NOMINE: Leomeccanico, Babysitter e SquadroneVolante 

 ha scritto nel messaggio 
news:BDV9e.58546$IN.10...@twister2.libero.it...
Cax, scusate per la firma, ma a forza di far post,
mi è scappata la versione completa!


 mi è scappata la versione completa!
Ciao,
no ho visto la tua applicazione e quindi parlo sull'idea che mi sono fatto
leggendoti.
credo che tu abbia un db molto dispersivo.
tra l'altro no so neanche se si possono fare più di 250 maschere, ma tant'è
già quelle sarebbero troppe.
Io spesso uso maschere "riutilizzabili" e soprattutto funzioni richiamabili
con parametri diversi:
questo per poter intervenire dove mi serve.
Spesso nelle maschere ci sono solo call è poi nei moduli che mi gioco la
partita.
bisognerebbe capire cosa fanno quelle macro, ma credimi, le macro fanno ben
poco e solo di difficile gestione (metti per esempio un debug, come
lointerrompi?)
Per quanto riguarda le foto io sicuramente le metterei fuori in una cartella
a parte e le richiamerei dicendogli di andare a vedere il path del db più la
directory foto (anche perchè una penna usb viaggia al massimo a 8 mbit (e
stiamo parlando di usb 2.0), se il db è così (inutilmente) pesante, quanto
ci metti per aprirlo?
Portarti una directory in più non mi sembra una cosa assurda, senza
considerare la faciltà concui potresti inserire la foto.
Per quanto riguarda C come "editor" di FE la vedo dura e lunga e cmq ti
dovrai appoggiare ad un report maker e a delle tabelle Access se vuoi
tenerlo sulla penna SQL (o prodotti simili) se invece lo lasci sul pc del
cliente.
Rivedi un pò il tutto, e guarda soprattutto qualche lavoro di altri prima di
sindacare sulla poca professionalità dei prodotti Access


 quindi... nel possibile tito avanti così ;°)
Ma certo che va bene così!
Va molto meno bene "trollare" opinioni su quanto NON si conosce su aree
pubbliche  :-)
Ciao.

 sindacare sulla poca professionalità dei prodotti Access
No, non mo sarò spiegato bene, non dico che non sono professionali i prg
in Access...
ma che IO lo uso in modo un po "spannometrico".


 pubbliche  :-)
E chi ha trollato? ;°°°)
Solo perchè ho detto che FORSE tutto il paccone era più "bello" se
andava scritto in un'altro linguaggio, ma uso cmq lo stesso access ;ç)
Il bello che il paccone inizialmente nacque in Approach... uno era fissato
con quel programma ;°°°)
Sai io che imprecazioni in 3 mesi di "conversione/copia"? ;°)
Dopo 5-6anni di lavoro e continue patch/add, trovo spesso caxxate che
correggo man mano ;°)
Son felice di usare ACCESS, solo che lo uso in modo un po
improprio/spannometrico ;-)


 so cosa vorrei e come farlo, ma mi mancano leconoscenze...
Incredibile, quindi in 4 anni non hai mai compilato il db?


 Incredibile, quindi in 4 anni non hai mai compilato il db?
Premettendo che le mie conoscenze in programmazione
sono abbastanza limitate...
Domanda da primino: Cosa intendi per compilarlo ;°)
Trasformarlo in un prg vero e proprio (.exe)?
Non so come si faccia ;°°°°°)


 Non so come si faccia ;°°°°°)
No, vai in un modulo
Debug
compila
Lui ti evidenzia tutti gli errori nel codice.


 Lui ti evidenzia tutti gli errori nel codice.
Ah, non mi da errori ;°)
