Opgelost Keuzelijst wordt niet ververst na nieuwe invoer

[IOWA]

Goede middag.
Ik werk als vrijwilliger bij een Repair Cafe. Wij zijn een keer per maand open. Wij gebruiken hierbij een papieren reparatieformulier, dat door iedere klant bij binnenkomst moet worden ingevuld. Deze bonnen worden doorlopend genummerd en samen met het nummer van de maand vormt dat het ordernummer. Ik wil deze formulieren opslaan in een Access database.
Ik gebruik daarvoor Windows 11 en ACCESS 2021.
Ik heb in Access een paar tabellen gemaakt waarvan er 2 relationeel gekoppeld zijn en er 2 alleen gebruikt worden voor een keuzelijst. Voor de invoer en wijziging van de gegevens heb ik 2 formulieren gemaakt: "orderformulier" en "orderoverzicht".
In het orderformulier worden de papieren reparatiebonnen ingevoerd. In het orderoverzicht kunnen de orders per maand worden opgevraagd en geselecteerd voor bewerking. En hier ontstaat het probleem: Als ik het formulier "orderoverzicht" open en ik selecteer een maand (keuzelijst368), dan worden in de combobox (keuzelijst347) waarin de betreffende bonnummers geselecteerd kunnen worden, keurig de orders van die maand weergegeven. Maar als ik vervolgens een andere maand kies, dan blijven de eerder geselecteerde bonnummers in die combobox staan. Als ik het formulier sluit en weer open en een andere maand kies, dan zie ik wel weer de juiste bonnummers die daarbij horen. Lang verhaal kort: in de recordset die behoort bij de combobox "bonnummers" heb ik bij de maand (mnd) het criterium van de gekozen maand (keuzelijst368) ingegeven, maar deze wordt niet ververst als een nieuwe maand gekozen wordt.
Wie kan mij hierbij helpen. Ik heb het databasebestand RepairCafe.accdb bijgevoegd.
PS: de VBA code voor het filter van keuzelijst368 heb ik "gepikt" van OctaFish en dat werk goed!

 

[xps351]

maar deze wordt niet ververst als een nieuwe maand gekozen wordt

Dat klopt. Je roept de procedure "Filteren" aan en die past het filter van het formulier aan. En doet niets met met de tweede keuzelijst. In het formulier zien je wel de orders van die maand.

Voordat je dit oplost lijkt het me beter om eerst aantal structurele problemen aan te pakken, want OctaFish heeft je vast niet geleerd om:

• De maand én de datum op te slaan;
• Tabellen per jaar te maken;
• Cryptische veldnamen te gebruiken (naam in plaats van nm is een kleine moeite);
• Betekenisloze namen (Keuzelijst368) voor je controles te gebruiken;
• Tabellen zonder primaire sleutels te gebruiken;
• Geen relaties te leggen tussen "opzoektabellen" en de tabellen die er gebruik van maken.

Kortom: je database moet nodig naar het Repair Cafe om de ergste fouten er uit te halen. Daarna praten we verder.

 

[IOWA]

Hallo Peter,
Bedankt voor je snelle reactie.
Ik ben met je huiswerk aan de slag gegaan.
Punt 3, 4 en 5 zijn aangepast.
Ad punt 1: ik heb de maand nodig in de tabel omdat die samen met het bonnummer het unieke ordernummer vormt. Zo werkt ook de papieren administratie. De te repareren apparaten worden voorzien van een sticker met daarop het ordernummer.
Ad punt 2 : Een grote tabel over de jaren heen of voor elk jaar een nieuwe tabel? Dat is toch geen fout, maar en keuze? Wij kiezen voorlopig nog voor het laatste.
Ad punt 6: Daar gaat het over twee keuzetabelletjes met 2, resp. 4 records.

Ik hoop echt dat mijn aanpassingen en verdere toelichting gaan leiden tot de oplossing van het probleem.
Bij ons Repair Cafe hoef ik er niet mee aan te komen, die doen alleen maar hardware.

Met vriendelijke groet,
Ivan

 

[Haije]

Zou het niet handig zijn als je dhet aangepaste bestand plaatst?

 

[IOWA]

Hallo Haije, dat was ik inderdaad vergeten. Bedankt voor de tip

 

[xps351]

ik heb de maand nodig in de tabel omdat die samen met het bonnummer het unieke ordernummer vormt.

Dat is nog geen reden om de maand op te slaan. De maand kan je uit de datum afleiden. Daar zijn ook functies voor (Month(), DatePart() en meer).
En als je de maand al op zou willen slaan, doe dat dan in ieder geval automatisch. Als de gebruiker de maand in moet geven zoals in jouw database (de oorspronkelijke) leidt dat geheid tot fouten.
Het verhaal met de bonnummers begrijp ik sowieso niet helemaal. Je zegt dat ze doorlopend genummerd worden, maar ik zie dubbele bonnummers. Als het bonnummer echt uniek zou zijn, is het ordernummer overbodig. En ook hier geldt: als de gebruiker zelf het ordernummer moet invullen gaat dat zeker een keer mis.

Een grote tabel over de jaren heen of voor elk jaar een nieuwe tabel? Dat is toch geen fout, maar en keuze?

Het is maar hoe je het bekijkt.
Bij het ontwerpen van een relationele database gelden een aantal regels. Een van die regels is dat je gegevens opslaat in (velden van) tabellen. Klinkt als een open deur, maar houdt wel in dat je geen gegevens (zoals een jaartal) moet verstoppen in een tabelnaam.
Een andere regel is dat je geen redundante gegevens opslaat, omdat dat tot inconsistenties kan leiden.
Beide regels overtreedt je door het jaartal in de tabelnaam op te nemen. Waar dat toe kan leiden toont je database aan. Er zitten orders van 2026 in de tabel "Orders 2025".
Zelfs als je je niet aan de regels wenst te houden is het mijns inziens een slechte keuze om voor elk jaar een nieuwe tabel te maken. Het betekent dat je ieder jaar je formulieren en query's aan moet passen of extra formulieren en query's moet maken. Begin 2026 wil je vast nog wel de orders van eind 2025 kunnen bekijken.
Bovendien wil je misschien wel overzichten over meerdere jaren maken. Die moet je ook ieder jaar weer aanpassen omdat er een tabel bij is gekomen.
Met 1 ordertabel hoef je, zolang de wensen niet veranderen, nooit iets aan te passen en is de het Repair Cafe ook niet afhankelijk van jouw goedwillendheid.

Daar gaat het over twee keuzetabelletjes met 2, resp. 4 records.

Dat is waar, maar dat is geen reden om ervoor te zorgen dat met behulp van referentiële integriteit afgedwongen wordt dat de gebruiker een van die waardes kiest. Ook dat is een kwestie van zorgen dat de inhoud van je database consistent blijft.
Nu is het zo dat je bij "leeftijd" alles kunt invullen wat je wilt, ondanks het feit dat er een tabel is met de toegestane waardes. Als je een relatie had gedefinieerd en het vinkje "referentiële integriteit afdwingen" had aangezet, was dat niet mogelijk geweest.
Bij geslacht is het nog merkwaardiger. Daar maak je helemaal geen gebruik van de tabel. Bij de keuzelijst is het type rijbron een "Lijst met waarden", en niet "Tabel/query" zoals te verwachten viel.


Nog even een nabrander.
Kan het voorkomen dat een bezoeker met meer dan één apparaat aankomt?

Bericht automatisch samengevoegd: 21 jan 2026

Punt 3, 4 en 5 zijn aangepast.

Dat is niet te zien

Ik heb trouwens een voorzetje gemaakt hoe de structuur er volgens mij - gegeven een uniek bonnummer en onder voorbehoud van de nabrander - uit zou kunnen zien.

 

[IOWA]

Ik heb mijn oorspronkelijke probleem inmiddels zelf opgelost:

Private Sub klmaand_AfterUpdate()
     Me.klorders = Null
     Me.klorders.Requery
End Sub

Wij gaan ook jouw advies volgen om geen aparte jaargangtabellen te maken.
Bedankt voor alle aanbevelingen en suggesties.

Met vriendelijke groet,
Ivan

 

[lommer]

Precies te laat. Dat is hier al opgelost. Nu dat ik zelf een db had gemaakt.

 

[IOWA]

Hallo Lommer,
Maar ik ben wel héél blij met jouw database.
Als je het goed vind, ga ik daar mee verder en breid ik hem nog uit met de reparatieverslagen.
Hartelijk bedankt
Ivan

 

[lommer]

Goed om te horen dat de db je bevalt. Ik heb nog wat toegevoegd. Nu kun je bij Orders alle formulieren ingeven zonder dat je steeds moet terugkeren naar de lijst.

 

[IOWA]

Ja, we zijn er erg blij mee. "We" zijn mijn collega's van het Repair Café Strijen. We zijn, zoals eerder gezegd, vooral praktisch bezig met het repareren van apparaten van koffiezetapparaten tot platenspelers en krultangen. De administratie gebeurt nu op papier en een spreadsheet. Ik heb al wat met jouw db gestoeid. Maar ik ga nu eerst even kijken naar je nieuwste versie. Wordt vervolgd...

 

[IOWA]

Hallo Lommer,
Ik heb wel een probleempje ontdekt. De ordernummers moeten per jaargang uniek zijn.
De maand is leidend, daarbinnen mogen geen 2 dezelfde bonnummers voorkomen.

 

[IOWA]

Hallo Lommer,

Ik heb het probleem met de dubbele records inmiddels opgelost door een uniek veld toe te voegen aan OrdersF: ordnr-lang = jaar&mnd(jaar)&bnr als tekstveld van8 tekens.
Ik heb inmiddels e.e.a. doorgevoerd in de db en VBA codes en alles werkt uitstekend.

 

[xps351]

Dat zat eraan te komen: een slechte oplossing nog slechter maken door een extra redundant gegeven vast te leggen en een samengesteld gegeven nog samengestelder te maken.
Het echte probleem is hier mijns inziens dat de systematiek van bonnummers in de echte wereld niet klopt. Door elke maand opnieuw te beginnen met bonnummer 1 kan je bonnen op basis van het bonnummer nooit terugvinden. Dan is het bonnummer feitelijk nutteloos. Nu los je het op door kunstmatig een ordernummer in elkaar te flansen. Dat het kunstmatig is zie je ook terug aan het feit dat je geen behoefte hebt aan aparte tabellen voor bonnen en orders. Het is eigenlijk hetzelfde.
Dus: bonnen doorlopend (laten) nummeren.

Ondertussen blijft de vraag of je model wel klopt voor situaties waarbij een klant met meerdere apparaten arriveert of later nog eens terugkomt, al dan niet met een ander apparaat.

En nog een laatste bommetje: de privacy.
Je legt persoonsgegevens vast en bent dus vanzelf gebonden aan de privacywetgeving (AVG). Die schrijft onder meer voor dat je moet verantwoorden waarom je bepaalde gegevens vastlegt. Het lijkt me sterk dat jullie als iemand een klacht indient bij de Autoriteit Persoonsgegevens (AP) jullie de AP ervan kunnen overtuigen dat je leeftijdscategorie van de eigenaar nodig hebt om een broodrooster te kunnen repareren.