:strip_icc():strip_exif()/u/17623/crop60195077a696c.jpeg?f=community)
Ik heb een database met daarin financiele gegevens. Nu heb ik laatst de backend in een mySQL-server gezet zodat ik er ook via internet bij kan.
Alleen zie ik nu iets raars: in de database is het mogelijk om andere valuta te gebruiken voor bijv weergave.
Zo kan ik schakelen tussen de gulden (is al een oud systeem) en de euro.
Nu ik echter de database in MySQL heb staan heb ik ineens andere jaartotalen. Dat blijkt te komen door afrondingsverschillen: bij het weergeven van alle posten doe ik nl het volgende in bijv. een query:
[gekozen valuta]/[boekingvaluta] * bedrag = weergavebedrag
Dus: als ik guldens (=2,20371 euro) gekozen heb voor weergave, maar de post is opgeslagen als euro (=1,00 euro) krijg je: 2,20371/1 * bedrag, of andersom.
Nu gebruik ik natuurlijk al lang geen guldens meer, dus in de praktijk wordt alles 1 op 1 berekend: ingevoerd als euro wordt weergegeven als euro, dus: [1]/[1] * bedrag
Het blijkt echter dat MSAccess, indien de data in MSaccess zelf staat, alle bedragen tot ver achter de komma uitrekent. Vreemd, want alle bedragen zijn tot 2 cijfers achter de komma ingevuld en worden met 1/1 vermenigvuldigt
7053,26 euro wordt dus in de query weergegeven als 7053,259765625. De berekening die plaatsvind is dus: 1 / 1 * 7053,26 = 7053,259765625
Dit is niet het geval bij gegevens die zonder decimalen ingevoerd zijn, bijv. 1000 euro
Maar: Als de data in mySQL staat worden álle cijfers met maximaal 2 (correcte) decimalen weergegeven.
Veld in MSAccess: enkele precisie met 2 decimalen
Veld in MySQL: double(7,2)
Nu denk je misschien: wat maakt dat uit als het nu wel goed gaat? Het blijkt dus nu dat alle jaaroverzichten in MSAccess met allerlei afrondingsverschillen zijn opgemaakt (en daar zijn onder andere bepaalde belastingopgaven op gebaseerd). Dus: een historie van kleine afrondingsverschillen, en daar loop ik nu tegenaan.
Als ik nu dezelfde overzichten uitdraai uit de database in MySQL krijg ik allemaal afwijkende getallen en klopt er eigenlijk niets meer van de administratie.
Iemand die het nog kan volgen?
Het heeft waarschijnlijk iets te maken met de veldeigenschappen en gevolgen van bijv. een enkele precisie die ik blijkbaar niet heb gekend, maar ik moet wel een oplossing bedenken. Ik zoek dus iets van een verklaring van het probleem, oorzaak, zodat ik wat gerichter kan zoeken wat de oplossing is
edit: ik heb zojuist het veld in MSaccess in een kopie database naar "Decimaal, met lengte 9 en 2 decimalen, gezet en nu doet de query die verkeerde "afrondingen" niet meer. Op de overzcihten zie ik echter nog wel de afrondingsverschillen.
Alleen zie ik nu iets raars: in de database is het mogelijk om andere valuta te gebruiken voor bijv weergave.
Zo kan ik schakelen tussen de gulden (is al een oud systeem) en de euro.
Nu ik echter de database in MySQL heb staan heb ik ineens andere jaartotalen. Dat blijkt te komen door afrondingsverschillen: bij het weergeven van alle posten doe ik nl het volgende in bijv. een query:
[gekozen valuta]/[boekingvaluta] * bedrag = weergavebedrag
Dus: als ik guldens (=2,20371 euro) gekozen heb voor weergave, maar de post is opgeslagen als euro (=1,00 euro) krijg je: 2,20371/1 * bedrag, of andersom.
Nu gebruik ik natuurlijk al lang geen guldens meer, dus in de praktijk wordt alles 1 op 1 berekend: ingevoerd als euro wordt weergegeven als euro, dus: [1]/[1] * bedrag
Het blijkt echter dat MSAccess, indien de data in MSaccess zelf staat, alle bedragen tot ver achter de komma uitrekent. Vreemd, want alle bedragen zijn tot 2 cijfers achter de komma ingevuld en worden met 1/1 vermenigvuldigt
7053,26 euro wordt dus in de query weergegeven als 7053,259765625. De berekening die plaatsvind is dus: 1 / 1 * 7053,26 = 7053,259765625
Dit is niet het geval bij gegevens die zonder decimalen ingevoerd zijn, bijv. 1000 euro
Maar: Als de data in mySQL staat worden álle cijfers met maximaal 2 (correcte) decimalen weergegeven.
Veld in MSAccess: enkele precisie met 2 decimalen
Veld in MySQL: double(7,2)
Nu denk je misschien: wat maakt dat uit als het nu wel goed gaat? Het blijkt dus nu dat alle jaaroverzichten in MSAccess met allerlei afrondingsverschillen zijn opgemaakt (en daar zijn onder andere bepaalde belastingopgaven op gebaseerd). Dus: een historie van kleine afrondingsverschillen, en daar loop ik nu tegenaan.
Als ik nu dezelfde overzichten uitdraai uit de database in MySQL krijg ik allemaal afwijkende getallen en klopt er eigenlijk niets meer van de administratie.
Iemand die het nog kan volgen?
Het heeft waarschijnlijk iets te maken met de veldeigenschappen en gevolgen van bijv. een enkele precisie die ik blijkbaar niet heb gekend, maar ik moet wel een oplossing bedenken. Ik zoek dus iets van een verklaring van het probleem, oorzaak, zodat ik wat gerichter kan zoeken wat de oplossing is
edit: ik heb zojuist het veld in MSaccess in een kopie database naar "Decimaal, met lengte 9 en 2 decimalen, gezet en nu doet de query die verkeerde "afrondingen" niet meer. Op de overzcihten zie ik echter nog wel de afrondingsverschillen.
[ Voor 9% gewijzigd door Stefke op 16-06-2012 20:43 ]