Overloop fout in rapport

Ik heb een rapport gebaseerd op 1 tabel en 2 query's, geeft precies wat ik wil zien alleen het is de complete data opgebouwd in zo'n 7 jaar.

Ik wil dan ook filters inbouwen. De data betreft met name 3 kolommen met aantallen. Ik heb wat expressies toegevoegd die bijv. kol1, kol 2 en kol3 optellen, geen probleem.

Ik wil echter vooral filteren op het sommetje (Kol2+kol3)/(kol1+kol2+kol3) uiteraard nog met wat [] en weergegeven als percentage. Op het gegevensblad krijg ik keurig de juiste waarden.
Als ik er echter op wil filteren werkt dat op het gegevensblad maar wil ik het rapport zien krijg ik de melding overloop. Al verschillende instelling geprobeerd en ook filteren met een waarde die van een formulier wordt gehaald waarbij dat veld ook als percentage is ingesteld werkt niet. Ook ingesteld als getal lukt het niet.

Werkt het wel als ik dat percentage in een aparte query bereken en die query toevoeg? Waarom werkt het wel met de optellingen en niet met de combi optellen/delen?

Zonder voorbeeldje heb ik geen antwoorden . Maar je geeft zelf al de beste remedie: zet berekeningen (zeker als ze voor een rapport zijn) bij voorkeur in de query zelf. Een rapport is wat ingewikkelder dan een formulier qua verwerkingen, dus ik snap wel dat je deze melding krijgt. Dus zet zoveel mogelijk in de query. Bij voorkeur dus óók het filter.

De berekening zit in de expressie die in de query staat, niet in het rapport.
Voorbeeldje op dit moment is lastiger, iets met Citrix ;-)

Maar ik bedoelde een aparte query die alleen het percentage uitrekent en toegevoegd wordt aan de overige.

Je vroeg of het beter was om de berekening in de query te zetten, en daar gaf ik antwoord op . Als de berekening daar al staat, dan is dat uiteraard prima. Waarom een aparte query om het percentage uit te rekenen? Lijkt mij zinloos.

Hallo,

als de expressie te complex wordt om te evalueren kan je inderdaad proberen om die te vereenvoudigen door deze in 2 stappen te doen. Maar je kan dit moeilijk in dezelfde query omdat het berekende veld nog niet bestaat als je de WHERE expressie gaat uitvoeren of een extra veld aan de FROM clause toevoegt (zie bijgevoegd extract uit de SQL cursus). Dus moet je al een tweede query maken die je baseert op de eerste en waar je het percentage in berekent, of je berekent de waarde in de query en het percentage op het rapport.

Maar ik denk dat je expressie niet zo ingewikkeld is, maar dat je een probleem hebt met een lege waarde. Als er ergens een lege waarde zit in kol1, kol2 of 3 dan geldt kol1 + kol2 + kol3 is null. En als je probeert te delen door een lege waarde krijg je natuurlijk een overflow.
Probeer misschien eens de NZ functie te gebruiken om de lege waarden te vermijden.

Veel succes
Noëlla

Ik heb nu alle berekeningen uit het rapport en in 2 van de 3 query's waarop het rapport is gebaseerd gezet.
Ik kan nu inderdaad op alle velden selecteren behalve die waarin een percentage is uitgerekend en daar zit uiteraard een deling in. In principe kan dat nooit een deling door nul zijn, maar ik heb al rare invullingen gezien in het bestand. Zal eens kijken of er toch niet nog ergens een rare invulling tussen zit. In gegevens blad zag ik wel enkele keren een foutmelding staan wegens delen door nul maar dacht die uitgefilterd te hebben doordat deze ook een laag kenmerk hadden, wat per definitie niet klopt omdat dat minimaal 6 cijferige kenmerken zijn.
Even het NZ geheugen opfrissen.......

Kom opmerkelijk veel records met totaal 0 tegen, toch apart voor een applicatie die juist aantallen registreert. Collega's blijken opmerkelijk vindingrijk te zijn in omzeilen van invulverplichtingen.
Laten we het maar op houden dat het komt door netwerkstoring tijdens het invullen, al wel de leverancier maar nog niet de aantallen, is nog geloofwaardig ook helaas.

Ik verwacht dat het probleem hiermee opgelost zal zijn.

Nu iets verzinnen om dit te voorkomen...........

Johgs zei:

Nu iets verzinnen om dit te voorkomen...........

Klik om te vergroten...

Mag toch niet zo'n probleem zijn? Als je het écht af wil dekken, maak je formulier dan niet-afhankelijk en gebruik een recordset om het complete record toe te voegen aan de tabel. Je kunt dan bij het opslaan checken of alle verplichte velden zijn ingevuld.

Dat zou inderdaad een oplossing zijn, ware het niet dat niet alle velden verplicht zijn. Ik zit nu te denken aan iets als (veld1 + veld2 + veld3 + veld4) >0 And [
leverancier] is not null en standaard ingevulde waarden van 0.
Een levering is per definitie groter dan 0 en moet een herkomst hebben maar het aantal kan volledig in veld1 komen (normaal) maar ook deels in de overige velden naarmate de hoeveelheid schade.

Als je het visueel wil maken voor de gebruikers kan je misschien een extra berekend veld op je formulier plaatsen waarin je de som van de velden in het rood toont als het nul is. Bij gebruik van een niet afhankelijk formulier kan je dan zelfs de 'SAVE' knop disabeld houden zolang niet alle voorwaarden voldaan zijn. Dit kan door bv. bij alle meespelende velden bij de after update event een code te zetten zoals me.mybutton.enabled = (me.veld1 + me.veld2 + me.veld3 + me.veld4) >0 And me.leverancier is not null