[Access 2010] Checkbox aanvinken en data kopieren

[rrutger]

Allereerst: ik ben een redelijke leek wat betreft het opbouwen van Access-databases, en heb op internet en in boeken geen duidelijk antwoord gekregen op onderstaand 'probleem'.

In een reeds bestaande (niet zelf gebouwde) database heb ik onder andere de formulieren (en tabellen) 'Familie' en 'Inschrijvingen 2011', waartussen nog geen relatie is aangemaakt. Op beide formulieren kunnen contactgegevens ingevuld worden. Op het formulier 'Familie' heb ik de checkbox 'Inschrijving 2011' gemaakt.

Ik zou graag willen dat bij aanvinken van deze checkbox de contactgegevens (sleutel (familienummer), naam, adres, tel.nr, geboortedatum etc.) van de record van het formulier (tabel) 'Familie' gekopieerd worden naar een nieuwe record in het formulier 'Inschrijvingen 2011'.

Het lijkt mij dat dit mogelijk is, maar hoe?

[Marko_J]

Uiteraard mogelijk. Maar belangrijker is de relatie tussen de tabellen. Kunnen familieleden zich meermaals inschrijven? Kan 1 inschrijving uit meerdere families bestaan? Of zitten er in beide tabellen uiteindelijk evenveel records? 1 inschrijving = 1 familie?

[rrutger]

Per familie is er 1 contactpersoon, van wie de adresgegevens reeds op de familiekaart (formulier/tabel 'Familie') staan. De tabel 'Inschrijvingen 2011' is leeg (er staat slechts 1 'dummy-record' in om de opmaak te kunnen aanhouden).
De bedoeling is, dat wanneer ik op het formulier 'Familie' het selectievakje aanvink, Access de adresgegevens van de contactpersoon naar een nieuw record in de tabel/formulier 'Inschrijvingen 2011' kopieert, zodat ik zelf die records/adresgegevens niet hoef aan te maken. De gegevens van de overige familieleden voer ik daarna handmatig in in het formulier 'Inschrijvingen 2011', die zijn nu namelijk nog nergens ingevoerd. Ik hoop dat dit duidelijker is .

[CaptJackSparrow]

Je gaat juist nooit echt data kopiëren in de zin van duplicate data in verschillende tabellen genereren. Dan moeten al die duplicaten nl. ook allemaal aangepast worden als er iets in gewijzigd wordt (adreswijziging bijv.). Wat je doet is door relaties tabellen aan elkaar koppelen waardoor je juist maar één exemplaar van bijvoorbeeld die adresgegevens in je database hoeft te hebben. Dat is nou juist het basisprincipe van een 'relationele database'. Daar gebruik je dan bijvoorbeeld één gemeenschappelijk veld per tabel voor.

Een formulier is ook iets heel anders dan een tabel. De tabellen zijn de 'database in engere zin' waar de gegevens in zitten. Met formulieren kun je die gegevens op het scherm weergeven om uit te lezen en in te voeren. Rapporten gebruik je om gegevens uit te kunnen printen. Query's kunnen als filter gebruikt worden om selecties uit de tabellen te maken voor weergave in formulieren of rapporten.

In Access zit net als in alle Office applicaties een heel behoorlijke helpfunctie. Ga daar in lezen over relaties (een op een/een op veel/veel op veel - een op veel komt het meest voor), sleutelvelden/primaire sleutel, autonummeringsvelden en referentiële integriteit. Dat zijn zaken die je zoal bij relaties tussen tabellen gebruikt. In de formulieren kun je data uit meerdere tabellen ophalen en laten zien.

Access is een krachtig programma en er kan heel veel mee maar het is zeker niet de makkelijkste applicatie uit het Office pakket. Als je er echt een beetje mee wilt werken is een leerboekje geen slecht idee. Dat moet je dan wel min of meer systematisch doorwerken totdat je voldoende basiskennis/inzichten hebt. Access is niet een programma waarmee je hier en daar wat functies kunt gebruiken. Je moet de onderliggende gebruikte functionaliteiten ook begrijpen en mee kunnen werken om die functies in de 'hogere lagen' te kunnen gebruiken.

Voor het ontwerpen van de tabellen en relaties heb je een helder inzicht nodig met welke gegevens je nu precies werkt, wat daar de mogelijke waarden van kunnen zijn en wat er precies moet worden vastgelegd/wat je wilt bereiken. Je informatie daarover is nogal spaarzaam.

Je gaat in de tabel "Inschrijvingen 2011" dus niet een duplicaat van die familie(adres?)gegevens zetten maar je koppelt ze aan elkaar via bijv. dat 'Contactpersoon' veld. Daar zul je dan een sleutelveld van maken. Als je dan in de "Inschrijvingen 2011" tabel datzelfde sleutelveld maakt en aanvullend velden maakt voor deelnemende personen aan die cursus/competitie/wat dan ook dan zijn via die link van de contactpersoon ook de adresgegevens van die familie aan die extra personen gekoppeld als dat is wat je wilt.

Overigens is een naam van een contactpersoon geen ideaal veld voor dit soort relaties want bij twee families met een "Arie" als contactpersoon wordt het al ingewikkelder. Dan moet je evt. de Familienaam als tweede sleutelveld in beide tabellen definiëren. Het is makkelijker om zo'n koppeling via bijv. een altijd uniek lidnummerveld te doen dat per familie is toegewezen.

Als een familie zich alleen maar wel of niet kan inschrijven voor één ding dan kun je een een-op-een relatie gebruiken. Ik heb de indruk dat dit hier het geval is. Als je dan een lidnummerveld in beide tabellen tot primaire sleutel maakt kun je er een een-op-een relatie tussen maken. Als je dan "Referentiële integriteit afdwingen" aanvinkt en "Gerelateerde velden trapsgewijs bijwerken" dan kun je in je formulier naast de velden voor de deelnemende familieleden ook de adresvelden uit de "Familie" tabel opnemen en die moeten dan in principe weergegeven worden.

[rrutger]

Ik snap het principe van een relationele database, en voordelen ervan wil ik juist gebruiken om niet alles te hoeven copy-pasten van de ene naar de andere tabel (wat het principe dus zou schaden).

Ik heb de Help-functie en een Access-boek/manual erop nageslagen, maar ik kom er niet uit, vandaar mijn hoop om op dit forum wel een antwoord te krijgen.

Ik ga inderdaad niet simpelweg een duplicaat maken, ik wil eerder ingevoerde gegevens in de 'hoofdtabel' kopieren naar een 'detailtabel', van waaruit ik weer een formulier heb gemaakt en later ook een rapport van wil maken.

• Beschouw elk record in de 'Familiekaart' als een klant, met naam- en adresgegevens, geboortedatum en een uniek studienummer (van 0001 t/m 0704) als primaire sleutel.
• Op de Familiekaart staat een selectiehokje 'Aanwezig 2011' (het gaat hier om een informatiedag).
• Wat ik wil, is dat een query nou juist die personen (incl. hun naam/adres/persoonsgegevens) selecteert, die dat hokje hebben aangevinkt (als het handiger is om hiervan een keuze Ja/Nee te maken, kan dat ook, maar dan zit ik met hetzelfde probleem dat ik niet weet hoe de select query te maken).
• Die (select) query wil ik gebruiken om de naam/adres/persoonsgegevens (incl. primaire sleutel uiteraard) van de Familiekaart-tabel te kopieren naar de Inschrijvingen 2011-tabel.
• Voor zover ik had begrepen, kan dit met een append query. Het probleem ligt echter in het maken van de eerdere select query die juist de 'aangevinkte personen' selecteert.
• De 'Inschrijvingen 2011' tabel is al aangemaakt, en bevat, naast een hoop andere gegevens, ook de primaire sleutel en de eerdergenoemde naam/adres/persoonsgegevens.
• Het zou handig zijn om een relatie tussen beide tabellen te hebben, zeker omdat adresgegevens tussentijds nog wel eens wijzigen. Het is hierbij dus wel zo dat de 'Inschrijvingen 2011' tabel niet alle 704 records bevat van de 'Familiekaart' tabel, maar alleen degenen die zich hebben ingeschreven in 2011.

Ik hoop dat dit één en ander opheldert, anders wordt het copy-pasten .

[CaptJackSparrow]

Dus je hebt al duplicate data staan in de twee tabellen begrijp ik. Foei!
Die adresgegevens kunnen het best weer uit die inschrijvingentabel lijkt me. Op grond van de tot nu toe beschikbare gegevens zie ik geen goede reden ze er wel in te zetten. Of moet die inschrijvingentabel elders in een andere database gebruikt worden?

Afhankelijk van wat er nou precies aan extra data in die inschrijvingentabel staat vraag ik me af of je überhaupt wel 2 tabellen nodig hebt en of je het niet met alleen een query af kunt.

Nou werkt dit niet echt lekker over een forum. Veel te veel variabelen. Het zou het handigst zijn als je die database met desnoods een paar (3-5) dummyrecords ergens zou kunnen neerzetten waar we er bij kunnen zodat het concreet te bekijken is en je e.e.a. ook even kunt uittesten.

[ Voor 15% gewijzigd door CaptJackSparrow op 18-02-2011 16:06 ]

[Lustucru]

rrutger schreef op vrijdag 18 februari 2011 @ 15:19:
Ik snap het principe van een relationele database.

No offence, maar daar zet ik een vraagteken bij. Pak eens een voorbeeld database van access en kijk hoe die is opgebouwd.


Je hebt dus uiteindelijk als het goed is het volgende:
familie (id,naw gegevens)
inschrijvingen (id, familie.id, inschrijfgegevens)
familieleden (id, familie.id, persoonsgegevens)
of
medeinschrijvers(id,inschrijving.id, persoonsgegevens)

In die laatste moet je een keuze maken, hangen medeinschrijvers aan een familie of aan een specifieke inschrijving?

De rest is een kwestie van relatie's leggen. Voor de invoerschermen heb je de volgende keuze's uit met hoofd en subformulieren werken en/of formulieren baseren op outer join query's of dropdownboxjes. Bv:
Een formulier met familiegegevens met een outer join op inschrijvingen. Vinkje zetten en de realtie is gelegd, of
Een formulie rinschrijvingen met een dropdownboxje op de familie_id
of combinatie's met hoofd/sub constructies.

Adresgegevens gaan copypasten, al dan niet automatisch, is een nogo.

[rrutger]

Het probleem is, dat ik aan de slag moet met een door iemand anders gemaakte database, die waarschijnlijk té snel té veel formulieren en tabellen heeft aangemaakt en dus het principe van de relationele database heeft gemist...
Omdat ik geen tijd heb om heel de database te herzien (en hiervoor ook te weinig zicht heb op de data), leek dit mij de meest voor de hand liggende 'oplossing' op korte termijn. Ik ga vandaag even kijken of ik e.e.a. kan herindelen om het wat gemakkelijk voor mezelf (en evt. voor jullie ) te maken.