Datum optellen

[Access2010]

Forum,

In mijn database die steeds fraaier wordt (dank aan de beantwoorders van vorige vragen) is de schadedatum los van het normale gebruik van datum, ook een waarde. Ooit leerde ik datums en procenten niet oiptellen! In de databse wordt het echter een noodzaak. Het aantal schadedatums wordt dus een totaalgetal aan het eind van een verslagmethode. Die uitkomst is ook bepalend voor een frequentieberekening.

In mijn accessbijbel inside/out kan ik het niet zo snel vinden. In de query gaat het wel (Som), maar omdat die alle jaren optelt is dat niet gewenst. Overigens ik krijg dat aantal niet in mijn formulier. Analoog aan de gestelde vraag en het antwoord daarop van selecteren per jaar moet dus het aantal schades in bijv. 2010 worden weergegeven en niet allemaal. Gedeeld door het aantal jaarvoertuigen is dat de frequentie.

Ik hoor graag.

Access2010

 

[OctaFish]

Wat wil je eigenlijk (op)tellen? Ik snap 't namelijk niet helemaal.... En wat 30% van 8 augustus is, kan ik je zo ook niet zeggen

 

[Access2010]

Even een voorbeeld:

Schade 1 valt op 20-1-2011 en nummer 2 valt op 23-03-2011. Het zijn 2 schades. De schadedatum (20-01-2011 + 23-03-2011) optellen gaat niet. Schadedatum zou dus een getal bijv. 1 moeten zijn om netjes 1+1 = 2 te geven.



Access2010

 

[OctaFish]

Ik krijg de indruk dat je alleen maar records wil tellen; da's heel erg simpel. Je kunt namelijk (bijna) elk veld wel gebruiken, dus een datumveld is dan helemaal niet nodig. De enige voorwaarde is, dat je 100% zeker moet zijn dat het veld gevuld is. Dus =Aantal([SchadeID]) levert hetzelfde op als =Aantal([SchadeDatum]). Of =Aantal([KlantID]). Je moet alleen uitkijken met velden die niet altijd gevuld worden, zoals Tussenvoegsel. De lege velden worden namelijk niet meegeteld.... Maar ook een veld als: =Aantal([Is de plantenbak omgereden Ja/NEe?]) levert hetzelfde resultaat, omdat een Ja/Nee veld per definitie altijd is gevuld.

 

[Access2010]

Een heldere uitleg die de oplossing heeft opgeleverd. Werkt perfect, inderdaad ja/nee werkt zo niet. Dat is jammer, is daar een oplossing voor?

Dank weer een stapje verder.

Access2010

 

[OctaFish]

Werkt perfect, inderdaad ja/nee werkt zo niet. Dat is jammer, is daar een oplossing voor?

Wat bedoel je hier mee?

 

[Harry46]

Tellen van records doe je eigenlijk niet op een veld maar met *, dus Count(*).
Overigens is een ja/nee veld niet per definitie gevuld, waarde kan ook null zijn!

 

[OctaFish]

Een Ja/Nee veld heeft waarde 0 of -1; null kan als je een Outer Join gebruikt. Overigens is het beter om op een veld te tellen, en niet op * omdat De query dan alle velden evalueert, i.p.v. het benoemde veld, en dat duurt (een fractie) langer. Wat ook perfect werkt: =Aantal([1]). Dan maak je dus een fictief veld waarop je telt.

 

[Harry46]

Overigens is het beter om op een veld te tellen, en niet op *

Dan heb je wat Access betreft een andere leerschool gehad dan ik. Access (Jet/Ace) is geoptimaliseerd voor tellen met *, en is daardoor duidelijk sneller.

 

[Access2010]

Michel,

Het veld heet Eigen schuld die wil ik tellen. Ik maak een fictief veld (zo heb ik er een groot aantal meer binnen een rendementsformulier).

=Aantal([1]) van Eigen schuld. Hoe zet ik die dan in een juist volgorde. Het veld koppel ik aan Eigen schuld in de Besturingselementbron. Zet ik daar =Aantal([1]) in dan wordt het niets. In alle combinaties niet.

Access2011
Still try to improve

 

[OctaFish]

Je telt ofwel een veld, ofwel op het * teken, ofwel op 1. de formules zijn dus resp.: =Aantal([Eigen schuld]), =Aantal(*) of =Aantal(1)

@Harry:
Een stukje theorie van TechOnTheNet:

Although inefficient in terms of performance, the following SQL statement would return the number of employees whose salary is over $55,000 per year.

SELECT COUNT(*) as "Number of employees"
FROM employees
WHERE salary > 55000;

It would return the following result set:

Number of employees
3

A more efficient implementation of the same solution would be the following SQL statement:

SELECT COUNT(1) as "Number of employees"
FROM employees
WHERE salary > 55000;

 

[Harry46]

Strekking van mijn opmerking is dat je niet over een veld telt als je null waarden wilt meenenem maar op *.
Het stuk waar jij naar verwijst met 1 gaat niet specifiek over Access. In Access handboeken ( o.a. Access Developer's Handbook) wordt * aangegeven als geoptimaliseerd binnen Access.

 

[OctaFish]

@Harry:
Probeer ook eens andere boeken, zou ik zeggen..... Bovendien is mijn ervaring (ja, uit de tijd dat een pc nog een 8086 processor had) dat je wel degelijk snelheidsverschil kon merken.
Ik ben het er uiteraard mee eens dat je niet over Null velden moet tellen, want dan klopt het resultaat niet.

@TS:

Ik maak een fictief veld (zo heb ik er een groot aantal meer binnen een rendementsformulier).
Het veld koppel ik aan Eigen schuld in de Besturingselementbron. Zet ik daar =Aantal([1]) in dan wordt het niets.

Je snapt geloof ik nog niet helemaal wat de bedoeling is van de formule. Wat jij een fictief veld noemt, is vermoedelijk een niet-gebonden tekstvak op het formulier. Een tekstvak kun je koppelen aan een veld, of niet. In het laatste geval is het dus een niet-gebonden tekstvak. In dat tekstvak wil je blijkbaar een telling hebben van het aantal records dat de kwalificatie [Eigen schuld] heeft. Dat doe je dus niet met de formule =Aantal(1), zoals je al gemerkt hebt. De formules die we steeds hebben gegeven, gebruik je in een query, zoals de query die je als basis gebruikt voor je formulier. Dat levert in je query dus een extra veld op. Ergo: om de uitkomst op je formulier te zien, zul je het tekstvak txtEigenSchuld dus moeten koppelen aan dit veld in je query.
Een ingewikkelder methode is om de query op te bouwen in VBA, en achter een gebeurtenis van een object te hangen, zoals <Na bijwerkern> van het formulier. De query moet je dan middels VBA en een recordset openen, en daarna het resultaat van de berekening op het tekstvak zetten.

 

[Access2010]

Heren,

Fraaie discussie die ik deels begrijp, maar lost mijn vraag niet op. veld =[Eigen schuld] Tellen met: =Aantal(1) maar dan geeft access WAAR.

Wat wordt dan de juiste expressie.

Access2010

 

[OctaFish]

Zoals ik al zei: de formule die je gebruikt werkt niet in een tekstvak. Die moet je in de query gebruiken die je voor het formulier gebruikt. Daarin wordt dus een extra veld aangemaakt, en dat veld koppel je aan het formulier.

 

[Tardis]

@Octafish,

ook hier geldt weer dat Harry het volkomen bij het rechte eind heeft.

Jammer dat je stug in je eigen perceptie en (gebrek aan) kennis en inzicht volhardt.

Tardis

 

[Harry46]

Fraaie discussie

In de begintijd van access-fora op internet (eind jaren 90) waren die er veel meer. Waardoor je Access beter zou kunnen begrijpen.
Helaas worden tegenwoordig opmerkingen meestal opgevat als een persoonlijke aanval.

 

[OctaFish]

@Harry

Helaas worden tegenwoordig opmerkingen meestal opgevat als een persoonlijke aanval.

Ach, dat valt wel mee. Al zit ik niet te wachten op de volkomen overbodige opmerkingen van Mr.T. , die blijkbaar vind dat hij je handje moet vasthouden in dit soort discussies ... Ik begin hem nu toch wel erg zielig te vinden. Het zou al een heel stuk schelen als hij wat nuttigs zou bijdragen. Wat ik dus wel vind van de bijdragen van Harry (al denkt hij vermoed ik dat ik daar anders over denk)

 

[Access2010]

En dit allemaal n.a.v. een vraag. Heren het gaat om een oplossing van een vraag en niet wie er gelijk heeft. Alle door Michel aangedragen oplossingen werken bij mij in access 2010 goed. Hij is door dit fora heen ook altijd degene die direct antwoordt geeft, verbeter daar waar nodig, maar schop elkaar a.u.b. niet voor de schenen daar is niemand bij gebaad en zeker dit forum niet. Gebrek aan kennis is een boude uitspraak. Had even snel de juiste oplossing gepost dan hadden wij dit soort stammenstrijd niet gehad. Een excuus al of niet via dit forum lijkt mij op zijn plaats. Men haakt dan af, en daar zit ik en vele met mij nu net niet op te wachten.

Terug naar de orde van de dag, de oplossing van mijn probleempje.

Michel dank voor je opmerking ik ga er mee verder.

 

[Harry46]

Had even snel de juiste oplossing gepost dan hadden wij dit soort stammenstrijd niet gehad. Een excuus al of niet via dit forum lijkt mij op zijn plaats

Ik weet niet voor wie je deze opmerking bedoelt, maar ik geef wel degelijk een antwoord.
Helaas heb ik mijn werkzaamheden en kan ik maar heel beperkt reageren.
In het verleden heb ik op andere fora, en in mindere mate op dit forum veel antwoorden gegeven vaak vergezeld van een voorbeeld.