Ik snap je gelukkig wel, en ook de denkwijze. Al is de vraag waarom je het op deze manier zou willen oplossen. Voorbeeldje: een instelling met twee filialen en in totaal 7 afdelingen heeft nauwelijks behoefte aan een dubbele keuzelijst waarin je eerst het filiaal filtert, en daarna de afdeling. Als je de keuzelijst met afdelingen opent, zie je immers gelijk al alle opties. Dus je maakt het de mensen dan moeilijker, niet makkelijker.
Anders is het als je 20 locaties hebt, en per locatie 30 afdelingen. Dan praat je over zo'n 600 afdelingen, en dan is het wél handig om de lijst te splitsen.
Daarnaast snap ik niet helemaal wat je van plan bent. Ik proef nog weinig doordachts, zo denk ik niet dat er een Functioneel Ontwerp is gemaakt? Je begint gelijk met de zin "Het formulier wordt een invoerformulier voor collega's". Dat is mij véél te vaag: om te beginnen is de belangrijkste vraag natuurlijjk: Wát gaat er ingevoerd worden? Waar is de database überhaupt voor? Je twijfelt zelf al of Accerss de beste keuze is, en ook dat is een teken dat e.e.a. bepaald niet goed doordacht is. Je begint namelijk eerst met vaststellen wat de
informatiebehoefte is, voordat je ook maar begint om aan een oplossing daarvan te werken. Laat staan dat je bij het begin al weet wat het beste programma is om die behoefte te verwezenlijken. Kan best zijn dat je na grondig onderzoek en denkwerk uitkomt op Access, maar dat is dan het resultaat van het proces. Niet het uitgangspunt.
Als je de informatiebehoefte hebt geïnventariseerd en uitgewerkt in een FO, kun je aan je tabellen beginnen te werken. En je queries. En dán pas je formulieren. Dan weet je dus precies wat je nodig hebt. De oplossing van Peter vind ik dan ook veel te kort door de bocht, al gebruik ik 'm zelf ook in bepaalde situaties wel. Want an sich werkt het prima om keuzelijsten te beperken op basis van gebruikers gegevens. Zelf gebruik ik liever een inlogscherm waar een gebruiker kan inloggen, met als standaard de gebruiker van de ingelogde account, maar je moet wel de optie overlaten om een andere gebruiker te kunnen kiezen lijkt mij. Maar ook dat is dus al een stap verder.
De cursus Access staat in de Handleidingen sectie. De knop daarvoor staat in de blauwe titelbalk.
Wat ik als oplossing gebruik voor een afhankelijke keuzelijst, is overigens een tabel die is gebaseerd op het stamboomprincipe. Daarbij leg je in de tabel alle objecten vast die je wilt kunnen kiezen. Die tabel bevat een sleutelveld, omschrijving en een ParentID (minimale inrichting
). Elke optie krijgt een sleutelveld (kan AutoNummer zijn). Te beginnen dus met de filialen, waarvoor het voldoende is om het ID aan te maken. Voor Afdelingen (als dat het volgende niveau is) maak je dus aparte records aan, weer met een eigen ID, eigen omschrijving maar nu vul je ook het ParentID veld in. Stel dat Locatie C gebruikt wordt dat ID 3 heeft, dan vul je dus in het ParentID de waarde 3 in. En zo vul je de hele tabel (
@peter: één tabel dus
).
Voordeel van deze constructie: je kunt net zoveel lagen toewijzen als je wilt. Stel dat je de afdelingen wilt opsplitsen in kamers. Geen probleem: je voegt gewoon een nieuw record toe, weer met ID en omschrijving, en nu vul je in ParentID de waarde in van de betreffende afdeling.
Hoe meer trappen, hoe meer keuzelijsten je op het formulier nodig hebt om te kiezen. Daarbij zet de eerste keuzelijst (de locaties) de waarden in de tweede, de tweede zet de waarden in de derde en zo verder.
Maar ik ben eigenlijk wel benieuwd naar wat je nu eigenlijk aan het maken bent
.
