Opgelost Waarde opzoeken via DLookUp

[jacw]

Goedemiddag,

Ik heb een tabel “periode” met de volgende veldnamen [begin datum] [eind datum] [periode]

Nu heb ik ook een formulier “werken” gemaakt met de velden: [datum] [route] [aantal uur] en [periode]

Het formulier werkt goed (diverse relaties gemaakt 1 op veel), alleen ik moet via een keuzelijst de juiste periode kiezen, graag wil ik dat automatiseren door in het formulier een standaarwaarde te creëren. Ik kom dan uit bij DLookUP, wat ik ook probeer krijg het niet voor elkaar.

=DLookUp("[datum]";"tblPeriode";"now() >= [Begin datum] And Date() <= [Eind datum]")

Wie kan mij op weg helpen met de juiste code.

Met vriendelijke groet,

JacW

 

[xps351]

Zoals je strings moet omsluiten met aanhalingstekens, moet je datums omsluiten met hekjes.
De opbouw van je conditie is bovendien niet juist. Zoals je hem nu opgebouwd hebt, wordt gekeken naar de strings '[Begin datum]' en '[Eind datum]'. Variabelen zoals die datums moet je buiten de conditie-string halen op op de waarde te kunnen selecteren.
En: je wil een periode ophalen geen datum.
Tot slot is het vreemd dat je de ene keer met now() vergelijkt en de andere keer met date(). De tijd is denk ik niet relevant.

Probeer eens:

=DLookUp("[periode]";"tblPeriode";"Date() >= #" & [Begin datum] & "# And Date() <= #" & [Eind datum] & "#")

Succes niet gegarandeerd, want niet getest. Het zou ook zomaar kunnen zijn dat je de begin- en einddatum even in US-formaat moet zetten.
Veldnamen met spaties zijn trouwens niet handig en begin- en einddatum zijn in het Nederlands sowieso 1 woord.

Verder heb ik niets op te merken

 

[jacw]

Heel erg bedankt voor je reactie, qua Nederlands heb je helemaal gelijk (Soms een drama).
Ik ben een amateur met het bouwen en hou me ben soms chaotische in het bouwen van een applicatie.
Ik heb het bestand bijgevoegd en laten openen op het formulier waar ik graag de periode als standaard waarde wil hebben ingevoegd, met als bron de [datum] in het formulier.

Alvast heel erg bedankt,
JacW

 

[xps351]

Ik kijk er vanavond naar.

 

[xps351]

Ik heb het maar even tot het om de vraag te kunnen beantwoorden minimaal benodigde terug gebracht. Ik liep voortdurend vast in "verrassende" opties.

Het lukt denk ik niet om het met een standaardwaarde op te lossen. Je kan pas gaan zoeken nadat de datum is ingevuld. Ik neem tenminste aan dat de ingevulde datum bepalend is voor de periode en niet de huidige datum (date()). Verder moet je er rekening mee houden dat er geen periode gevonden wordt.
Daarom heb ik een gebeurtenis "na bijwerken" op de datum-control gemaakt. Zodra je een datum kiest (en het veld verlaat) wordt er een stukje code uitgevoerd dat kijkt of er een periode is die aan de criteria voldoet. Merk op dat de IdPeriode opgehaald en vastgelegd wordt. Dat is immers de waarde waar je naar moet verwijzen en waarop (terecht) de relatie ligt.

Overigens zet ik vraagtekens bij het nut van het vastleggen van de periode in de tabel Werken. Het is immers een (van de datum) afgeleid gegeven en afgeleide gegevens leg je normaliter niet vast.
Mijn vraagtekens komen misschien ook voort uit het feit dat ik de bedoeling van de tabellen (nog) niet begrijp.

 

[jacw]

Helemaal geweldig. Het werkt perfect.
Wij werken per 4 week dus 13 periodes in een jaar waar door ik niet kan selecteren per maand hoe en welke route ik heb gereden in die tijd, vandaar dat ik in de tabel het periode nr als extra heb ingevuld waardoor ik in mijn rapport kan selecteren op een periode.

Maar nogmaals bedankt voor de supersnelle reactie.

Met groet,
JacW

 

[OctaFish]

Nog wat aanvullingen/opmerkingen van een afgehaakt lid .
Om te beginnen: je gebruik niet altijd de meest logische berekeningen/functies in je query. Zo filter je de begindatum door de huidige datum -60 te doen, maar dat is een beetje een bottebijl methode, omdat niet alle maanden hetzelfde aantal dagen hebben. Ik vermoed dat je twee maanden terug wilt kijken, en dat kun je letterlijk keurig uitrekenen met deze formule:

>=DateSerial(Year(Date());Month(Date())-2;Day(Date()))

Daarnaast heb je een vreemde manier om het jaartal te berekenen, daar heeft Access een veel betere functie voor:

Jaar: Year([Begin Datum])

Gebruik die functies dan ook.

Eén opmerking van Peter klopt niet heel erg, namelijk deze: "Het zou ook zomaar kunnen zijn dat je de begin- en einddatum even in US-formaat moet zetten." Eerst een 'foutje': je kunt met opmaak de visuele datum wel omzetten naar Amerikaans, maar niet de waarde. Dat heeft dus geen enkele zin, ook niet in de procedure die Peter gemaakt heeft. Daarnaast is er een prima methode om altijd met de juiste datum te rekenen, ongeacht of je met Amerikaanse datums of met Europese datums werkt, en ongeacht of je dat in een query doet of in VBA. En die is simpel gezegd: zet de datum om naar een getal, en verander dat getal in de query naar een datum. En dat ziet er dan zo uit:

iPer= DLookUp("[IdPeriode]","tblPeriode","Date() >= CDate(" & CDbl([Begin Datum]) & ")
And Date() <= CDate(" & CDbl([Eind Datum]) & ")")

Dit is overigens de VBA variant, in een query ziet hij er iets anders uit. Dummy code, want je tabel is niet ingericht op deze methode.

Ik heb de aangegeven richting in jouw formulier gezet, ik zag geen reden om dat formulier te verbouwen .

 

[jacw]

Dank je, voor je aanvulling.
Die bottebijl was in eerste instantie voor bedoeld dat ik niet moet scrollen om de juiste periode in te vullen. Op een gegeven moment zou je anders de keuze hebben uit 2 of meer dezelfde periodes.

Maar super dat jullie zo mee denken.

 

[xps351]

Ik dacht al, waar blijft @OctaFish toch . Het valt me in ieder geval mee dat hij niet begint over het gebruik van de gebeurtenis "na bijwerken". Dat was tenslotte altijd een van zijn favoriete stokpaardjes.

Het is goed te merken dat hij er een tijdje tussenuit is geweest. Zijn oplossing rammelt aan alle kanten.
Om te beginnen zoekt hij de de waarde van het veld periode op. Dat is niet de sleutel van de tabel Periode. Er zit zelfs geen unieke index op, dus er zouden zomaar dubbele waardes kunnen voorkomen.
Zijn code wordt alleen bij nieuwe records uitgevoerd, dus als je achteraf een Datum in de tabel Werken aanpast, wordt de periode niet mee aangepast.
Dat laatste is trouwens niet erg, want wat je je ook invult bij de datum, de periode wordt altijd 11:


Triest om te zien dat een voorheen zeer kundige helper in korte tijd zo erg is afgetakeld.

 

[OctaFish]

Het valt me in ieder geval mee dat hij niet begint over het gebruik van de gebeurtenis "na bijwerken". Dat was tenslotte altijd een van zijn favoriete stokpaardjes.

En dat moet ik zeker zeggen dat jij nog steeds zo dom bent om die gebeurtenis te gebruiken, i.p.v. de veel logischere <Bij klikken>? Waarom denk je dat ik met HelpMij ben gestopt?

Triest om te zien dat een voorheen zeer kundige helper in korte tijd zo erg is afgetakeld.

Nog triester om te zien dat ook jij bent afgezakt naar het niveau van een aantal andere 'helpers' hier die het leuk vinden om helpers de grond in te trappen. Ga zo door, en je krijgt vanzelf meer aanzien.

Normaal gesproken zou ik jou de eer niet gunnen van een antwoord, maar ach, ik ben toch weg. En jouw reactie is zó dom, daar moet ik, omdat ik anders vrees dat TS jou nog gaat geloven ook, wel op reageren.

Zijn oplossing rammelt aan alle kanten. Om te beginnen zoekt hij de de waarde van het veld periode op. Dat is niet de sleutel van de tabel Periode. Er zit zelfs geen unieke index op, dus er zouden zomaar dubbele waardes kunnen voorkomen.
Zijn code wordt alleen bij nieuwe records uitgevoerd, dus als je achteraf een Datum in de tabel Werken aanpast, wordt de periode niet mee aangepast.

Mijn oplossing werkt, en zal altijd blijven werken. Waarom? TS wil in de keuzelijst de records zien uit één bepaald jaar. Daar wordt op gefilterd met de begin- en einddatum. In de resultaatquery zit dus altijd maar één periode nummer, nooit meer. Je hebt dus helemaal geen ID veld nodig om de juiste periode te vinden. Ergo: je klaagt over een niet-bestaand probleem.
Natúúrlijk wil je alleen een standaardwaarde ingevuld hebben bij een nieuw record, wat is dat dus voor flauwekul opmerking van jou? Bestaande, reeds ingevoerde records moeten altijd hun waarde behouden, tenzij je dat zélf later om de een of andere reden wilt veranderen. En dat kan uiteraard.

Kom Peter, als je niet wil dat ik de 'controle' over het Access forum terug neem, moet je wél beter je best doen. Liever doe ik dat niet overigens, ik heb toch echt dingen te doen die véél leuker zijn dan mensen zoals jij van repliek te dienen.

 

[jacw]

Lieve Forum leden,


Ik ben al jaren lid van dit forum en op alle vragen die ik tot nu toe heb gesteld, ben ik altijd tot grote tevredenheid geholpen. Ik kan mij voorstellen dat jullie als deskundigen heel veel voorbij zien komen, van waarom doe je het zo wat minder slim. Als leek denk ik meestal in een query of een macro en van VBA blijf ik ver weg. Als ik dan toch een oplossing in VBA krijg dan probeer ik te doorgronden het hoe en het waarom. Als jullie een oplossing moeten vinden is het zo dat jullie in de hersenspinsels van de leden moeten duiken om toch er nog iets van te maken en dat doen jullie echt goed.

iig heel erg bedankt

 

[OctaFish]

Als leek denk ik meestal in een query of een macro en van VBA blijf ik ver weg.

Dit heb ik dus nooit gesnapt; de macro taal heb ik in al mijn jaren dat ik met Access werk nog nooit begrepen. Waarschijnlijk is mijn snappie daar te klein voor . Hoe dan ook: na een paar mislukte pogingen om de macro 'taal' te snappen ben ik overgestapt op VBA, en ik heb nooit meer omgekeken. VBA is zóveel makkelijker en simpeler te begrijpen dan die vermaledijde macrotaal!

Ik heb dus enerzijds enorme bewondering en respect voor mensen die hem wél snappen, en anderzijds een beetje medelijden met diezelfde mensen, omdat ze zich conformeren aan een 'taal' die enorm beperkt en ingewikkeld is, terwijl het zoveel slimmer is om die leertijd in VBA te steken .

Maar als je liever macro's maakt: vooral blijven doen natuurlijk. Werken met een pakket moet je doen op de manier die voor jou het beste werkt. Ongeacht wat de rest van de wereld zegt en denkt!

 

[xps351]

TS wil in de keuzelijst de records zien uit één bepaald jaar. Daar wordt op gefilterd met de begin- en einddatum. In de resultaatquery zit dus altijd maar één periode nummer, nooit meer.

TS wil dat op basis van de ingevulde Datum de periode automatisch ingevuld wordt. En dus ook dat als je de datum corrigeert de periode zo nodig mee verandert. En dat is precies wat mijn voorbeelddatabase doet.

Waarom je denkt dat het correct is om altijd de periode die loopt van 21-04-2025 tot en met 18-05-2025 te kiezen is me een raadsel. Zelfs als je de periode zou kiezen op basis van de huidige datum klopt dat niet.
Spoiler: je criterium doet niets en de DLookup komt terug met het eerste de beste record.