We hopen eigenlijk dat de voorbeelden voor zichzelf spreken
Overigens word het meestal ook nog wel uitgelegd ook. Ik probeer dat althans meestal wel.... Omdat je de voorbeelden blijkbaar al hebt, en zelf geen db hebt meepgepost, zal ik geen voorbeeldje meegeven, maar het principe kort proberen uit te leggen.
Om te beginnen: de koppelen tussen je relaties hebben niks te maken met het al dan niet automatisch invullen van gegevens op formulieren of in tabellen. In het Relaties venster leg je alleen de controles vast op de gegevens die je in tabellen mag invoeren. Zo is het praktisch gezien niet mogelijk om artikelen te verkopen die je niet hebt. Je zult zo'n artikel nooit uit het magazijn kunnen pakken, want het bestaat niet. Alleen weet een database dat uiteraard niet; als je niks regelt, kun je in de tabel Inkoop probleemloos artikelen registreren die niet bestaan. En dat wil je uiteraard niet. Dus leg je in het Relaties venster een koppeling tussen [Artikelnummer] in de tabel [Artikelen], en [Artikelnummer] in de tabel [Inkoop]. Die koppeling zegt feitelijk: je mag in de tabel [Inkoop] geen artikelnummers opslaan van artikelen waarvan je geen artikelnummer hebt in de tabel [Artikelen]. We noemen dat: Referentiële Integriteit afdwingen.
Dit principe werkt alleen als je in de tabel [Artikelen] van het veld [Artikelnummer] een sleutelveld hebt gemaakt. Want: hoe weet de database welk artikelnummer je bedoelt in de tabel [Inkoop], als je twee of meer artikelen hebt in de tabel [Artikelen] als de artikelen hetzelfde nummer hebben? Deze constatering brengt ons automatisch tot de conclusie dat je alleen maar kunt zeggen welk artikelnummer in de tabel [Inkoop] hoort bij het juiste artikelnummer in de tabel [Artikelen], als dat artikelnummer in [Artikelen] uniek is. In de tabel Inkoop is het uiteraard de bedoeling dat je een artikel uit [Artikelen] meer dan één keer mag bestellen. In de tabel [Inkoop] is het veld [Artikelnummer] dus nooit een sleutelveld.
Nu weer terug naar de vraag: hoe krijg je op het formulier Inkoop de klantgegevens te zien als je een klant kiest? En hoe de artikelgegevens als je een artikel kiest? Het antwoord daarop is: met tekstvakken die zijn gekoppeld aan de keuzelijsten. Als voorbeeld de keuzelijst Artikelen. (ik noem hem voor het gemak cboArtikelen). Deze keuzelijst gebruik je om een artikel te kiezen. Artikelen staan in de tabel [Artikelen] dus deze tabel gebruik je als basis voor de keuzelijst. In de tabel [Inkoop] sla je het artikelnummer op, dus dat nummer heb je in ieder geval nodig in de keuzelijst Verder is het handig als je kunt kiezen op naam, en je wilt ook nog de prijs zien van het artikel, en de verpakkingseenheid. Al deze gegevens staan in de tabel [Artikelen]. De keuzelijst stel je zodanig in, dat de eerste kolom wordt verborgen (doet Access automatisch als je de wizard gebruikt). Je ziet dus, als je de keuzelijst gebruikt, de Artikelnamen in de keuzelijst terug. Maar je slaat (heel belangrijk om te onthouden) de Artikelnummers op in de tabel!
Om de extra artikelgegevens te zien op het formulier, maar je extra tekstvakken. Deze koppel je niet aan een tabel of query, maar aan de keuzelijst. Immers: als je een artikel kiest, wil je de bijbehorende gegevens zien. Gelukkig kan dat heel simpel; je kunt namelijk verwijzen naar de verschillende kolommen uit de keuzelijst. Dat doe je door het Besturingselementbron van de tekstvakken te laten verwijzen naar de betreffende kolom uit de keuzelijst. In mijn voorbeeld staat het Artikelnummer in de eerste kolom, artikelnaam in de tweede, prijs in kolom 3 en verpakkingseenheid in kolom 4. Om nu de prijs in een tekstvak te laten zien, zet je in het tekstvak bij de eigenschap <Besturingselementbron> de volgende fomule: =[cboArtikelen].Column(2). Je zult nu zien, dat als je een artikel selecteert, de prijs netjes wordt getoond op het formulier. Vervolgens kun je hier weer, in combinatie met het veld [Aantal], berekeningen mee maken.
Moet het nog specifieker, dan hebben we toch echt je eigen db nodig
