Hvorfor beregnes gennemsnit at en række observanter forkert i for
Følgende talrække :
4,4,3,4,4,4,4,3,5,3,4,4,4,5,4,4,5,5,3,4,4,3,5,4,4,4,4,5,-, 4,4,5,4,4,4,4,3,4,4,5,4,4,5,4,4,5,4,4,4,4,4,4,4,4,4,4,4,4,
4,4,3,4,3,4,4,-,4
Ialt 67 observanter (heraf 2 blanke ) giver en sumværdi på 262
262 / 65 = 4,03076...... osv.
En isoleret beregning i i en forespørgsel giver den korrekte værde, men en tilsvarende i formularfod
=Gennemsnit([Observation_01]) giver 4,01650.....
Hvad er der galt ved fremgangsmetoden ????
Skrevet tir. d. 14. december 2004 kl. 13:58:29| #1
Very likely becaus eAverage is also taking the two blank into concideration
Skrevet tir. d. 14. december 2004 kl. 14:02:39| #2
If you make aquery where you only select those not blank, then use Gennemsnit what do you get?
Skrevet tir. d. 14. december 2004 kl. 14:03:59| #3
Terry ..... 262 / 67 = 3,91044.... :o) ....
Skrevet tir. d. 14. december 2004 kl. 14:04:30| #4
262/67 giver heller ikke 4,01650 (nærmere 3,9104477611940 hvis jeg lige kan regne rigtigt i hovedet, haha)
Skrevet tir. d. 14. december 2004 kl. 14:04:43| #5
ah....du fik det samme :o)
Skrevet tir. d. 14. december 2004 kl. 14:06:12| #6
yes, I know this but the records are very likley being taken into account in some way!
Skrevet tir. d. 14. december 2004 kl. 14:06:26| #7
I also went to school :o)
Skrevet tir. d. 14. december 2004 kl. 14:08:14| #8
Jeg har ofte døjet med decimaler, når jeg skulle beregne noget. Sjovt nok duer en computer ikke til at regne rigtigt :-[
Se evt dette spm, som jeg selv oprettede for et stykke tid siden - måske kan det hjælp dig:
http://www.eksperten.dk/ (...)
Skrevet tir. d. 14. december 2004 kl. 16:33:25| #9
Debug med færre, overskuelige tal, f.eks. 4,-,4,4,-,4
Skrevet ons. d. 15. december 2004 kl. 09:09:18| #10
Suk ... løsningen blev, at beregningen foretages i en forespørgsel ( som gør det korrekt ), hvorefter formularfoden genereres v.h.a. DLookUp() ....
Mindre fancy, tidskrævende, men det virker ...
Skrevet ons. d. 15. december 2004 kl. 09:18:20| #11
Thomas & Terry, læg lige svar, så fordeler jeg point for jeres kreative indsats :o)
Skrevet ons. d. 15. december 2004 kl. 13:21:23| #12
ja, det er noget skidt noget :o(
Skrevet ons. d. 15. december 2004 kl. 13:24:13| #13
Umiddelbart må der vel være tale om en fejl i Access, når beregningen i en forespørgsel alene udløser det korrekte resultat. Det er jo kun i forbindelse med beregningen i formularfoden der genereres beregningsfejlen ....
Skrevet ons. d. 15. december 2004 kl. 13:27:19| #14
Ja, det er klart, at den må benytte 2 forskellige metoder. Hvorfor ved jeg ikke?
Skrevet ons. d. 15. december 2004 kl. 13:28:19| #15
Vi må have fat i Bill c",)
Skrevet ons. d. 15. december 2004 kl. 13:34:23| #16
Eller mister "Intel" (eller hvad han nu måtte hedde), hvis fejlen i virkeligheden skyldes maskinens evne til at regne med decimaler.
Skrevet ons. d. 15. december 2004 kl. 13:40:02| #17
Never mind ... problemet er løst, men som altid dukker der noget op i kølvandet, nemlig opdateringshastigheden, idet der på baggrund af middelværdien skal returneres en farvekode ( rød/gul/grøn ) af hængig af det opnåede resultat.
Da den nu benytter DLookUp() som mål, returneres farven grå helt vilkårligt ved åbning af formulen ... suk
Skrevet ons. d. 15. december 2004 kl. 13:59:19| #18
Brug VBA til at skrive værdien i en ubunden tekstboks. Læg koden på Form_Current og Form_AfterOpdate
Me!teksboks = Dlookup("....")
Mn bør altid benytte denne metode i stedet for at have beregnede felter direkte på formularen. Det går meget hurtigere!
Skrevet ons. d. 15. december 2004 kl. 14:05:02| #19
Afrund(DLookUp("[1]";"qryScore(Sum)";"")) benyttes i fbm. betinget formattering ... dette kan vel ikke gøres anerledes ?
Skrevet ons. d. 15. december 2004 kl. 14:09:06| #20
ah, jeg var ikke klar over, at det var i betinget formattering, at du benyttede Dlookup'en...
Skrevet fre. d. 17. december 2004 kl. 11:52:56| #21
Skrevet fre. d. 17. december 2004 kl. 11:54:36| #22
Skrevet fre. d. 17. december 2004 kl. 11:56:16| #23
Skrevet fre. d. 17. december 2004 kl. 12:45:09| #24
