05. februar 2002 - 13:38Der er
19 kommentarer og 2 løsninger
For mange decimaler!!!
Jeg har en db, hvor der foretages en del registreringer af forskellig art og nogle formularer, hvor der bl.a. er nogle lister, som viser diverse nøgletal fra disse registreringer.
Listerne har 1-2 kolonner, hvor rowsource er forespørgsler. Det virker alt sammen fint, hvis det ikke lige var fordi, der er ofte er alt for mange decimaler. Alle registreringer er på 2 decimaler, men der kan sagtens blive vist 10 decimaler - dette er naturligvis forkert, da der kun skulle kunne blive vist max. 2 decimaler!
Et nøgletal som f.eks. skulle være 0 (nul), hvis man regner manuelt efter, bliver vist som -1,48713588146E-05. Med andre ord et meget lille tal!
Hvorfra og hvorfor kommer der så mange decimaler - og hvordan slipper jeg af med dem?
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Du kan sætte dine beregninger ind i Format()-funktionen..
Hvis din Rowsource fx. er: SELECT ID, Sum(etellerandet) FROM... Så kan du bruge SELECT ID, Format(Sum(etellerandet),"#.##0,00") FROM ... for at få tusindestalsseperator og 2 desimaler.
>>>terry Ved lister (list) er der ikke en sådan valgmulighed. Det du snakker om, må være den indstilling som f.eks. findes ved tekstfelter (textfield).
>>>proaccess Det hjalp, da jeg brugte din funktion og byttede om på komma og punktum (ellers fik jeg 5 decimaler)!
En sidste detalje ville dog være at få diverse tal stillet under hinanden efter kommaet (eller alternativt højrestillet). Selv om jeg piller ved "tekstjustering" og sætter den til højre, står det stadigvæk venstrestillet. I lister med kun 1 kolonne er der kun tal, mens der er tekst i første kolonne og tal i anden i lister med 2 kolonner. Problemet er det samme i begge typer lister.
Kan det evt. lade sig gøre at få højrestillet tallene og venstrestillet teksten?
I am referig to the TABLE design, not a report, I assume its a report you mean when you say "lister"?
You should be able to set the fields "Text Alige" property (in the report) to Right. If it still doesnt aligncorrectly then I susspect that your data is getting formatted as text, with trailing spaces.
Det er et evigt tilbagevendende problem, det nemmeste jeg kan foreslå dig er at bruge en ikke-propertional skrifttype og derefter bruge foranstillede 0'er... som dog absolut ikke er nogen go' løsning... ;-(
>>>terry De pågældende lister befinder sig på formularer, da de bruges til at afspejle ændringer i forbindelse med indtastning af diverse registreringer.
>>>proaccess Kan det heller ikke lade sig gøre, hvis der kun er en kolonne?? Hvis det kan, kunne jeg jo bryde listerne med 2 kolonner op i 2 lister...
>Terry: You can set the Format of attributes in the tabledesign, right... BUT this is results of a calculating query... so the decimals are off... a number of 3 decimals times a number of 3 decimals, could return a result of 9 decimals...
Lige for at kunne runde spørgsmålet af: Kan det ikke lade sig gøre at få højrestillet tal i en liste - selvom listen kun består af 1 kolonne, som udelukkende indeholder tal??
Hvordan kan det være, at en forespørgsel, som lægger 2-decimalede tal sammen, kan blive til f.eks. 10 decimaler?? (Der er nu styr på at skjule de resterende decimaler, men hvorfor dukker du overhovedet op???)
The decimal places in the table properties only effects what is displayed NOT what is stored, so the query would still calculate correctly. But then you would still need to use the format or something if the result is giving too many decimals anyway!
Hvis du ikke skal bruge flere end 4 decimaler, så kan du med fordel bruge CURRENCY (valuta)... Den regner med skalerede heltal, i stedet for flydende kommatal (som er roden til alt ondt i dette tilfælde)
MHT: højrestilling, så er det ikke min stærke side, det er vist IKKE helt nemt at få til at spille...
>>> Hvorfor dukker de (decimalerne) op? Vi har tidligere vendt sagen med Microsoft, som svarer at regnefejlen er "as per design". Access er (ifølge Microsoft) ikke konstrueret til at kunne regne. De ævler om, at det er *svært* at foretage nøjagtige beregninger osv. osv. Tilbage sidder vi så med et program, hvor alle beregninger skal afrundes via hjemmestrikkede funktioner - selv helt enkle beregninger, f.eks:
Sub AccessRegneFejl() Dim a As Single Dim b As Single a = 16.22 b = 16.11 MsgBox (a - b) End Sub
Emnet har været vendt adskillige gange her på Eksperten. Du er ikke alene med dine frustrationer.
Jeg stiller mig tilfreds med svarene. De har givet mig indsigt i et problem, som åbenbart ikke er ligetil at løse, men samtidig givet mig mulighed for at komme videre...
>>>fdata Sender du lige et svar, da jeg synes, at du skal ha' en lille bid af kagen?
>fdata: du vil få præcis samme fejl i fx. excel... selv ved dit simple eksempel.
Dette skyldes at vi (mennesker) snakker efter 10-tals systemet, hvorimod at maskiner snakker binært 0/1... Der sker så af og til fejl, i konverteringen mellem disse systemer, som eksemplet illustrerer.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
