Hulp gezocht bij het opzetten van een database

[klad]

Beste forumleden,

Ik heb helemaal geen ervaring met een database; maar met Excel lukt het me niet om de gewenste informatie te beheren. Na een aantal weken (af en aan) te proberen iets in Access op te zetten is het mij nog steeds niet gelukt om dit onder de knie te krijgen.
Helaas heb ik geen voorbeeldtemplate of sjabloon kunnen vinden waarbij ik met wat kleine aanpassingen aan de slag zou kunnen.

Wat ik graag wil maken is een overzicht maken (en bijhouden) van foto's en informatie die ik op internet plaats. Ik heb in Excel een schema gemaakt, ik hoop dat de bedoeling hierin duidelijk is uitgelegd . Bekijk bijlage Wiki.xlsx

Is hoop dat iemand hiervoor een geschikt sjabloon heeft, of dat iemand mij hier een zetje in de goede richting kan geven? Als ik eenmaal een goede basis heb lukt het mij vast wel om, daar waar nodig e.e.a. aan te passen.

Mvg,
Katrien

 

[OctaFish]

Hoi Katrien,

Allereerst welkom bij HelpMij!
Je hebt volgens mij niet zo'n ingewikkelde database nodig, en ik vermoed dat je wel een willekeurige sjabloon van Microsoft had kunnen pakken. Die hebben dan weliswaar tabellen met verkeerde veldnamen, maar dat is niet zo'n groot probleem. Al is zelf bouwen meestal wel beter, omdat je dan precies dát kunt maken dat je nodig hebt. In jouw geval zie ik een aantal stamtabellen zoals [tblStatus], [tblSoort_Bijdrage], [tblBestemming] en [tblActies]. deze tabellen dienen als bron voor keuzelijsten die je op een formulier kan maken. De hoofdtabel heb je gek genoeg niet in je voorbeeldje gezet, en dat is eigenlijk wel vreemd . Het gaat er uiteindelijk om dat je de gegevens op de goede manier samenbrengt. Ik zou zeggen dat je daar één tabel voor gebruikt waarin je alle WikiEntries in opneemt, met datumvelden en opmerkingveld en wat je nog meer nodig hebt, dat je voor alle keuzelijsten enkelvoudige velden gebruikt, maar voor [tblBestemming] een meervoudig veld, zodat je meerdere opties kunt aanklikken. En voor de acties maak je een tabel WikiEntries_Acties waaraan je op je subformulier (hangt namelijk straks aan [tblWikiEntries]) de tblActies als keuzelijst koppelt. Voor de acties wil je natuurlijk ook weer datums vastleggen.

Wat ik eigenlijk mis (en daarom ontbreekt ook de belangrijkste tabel in je plaatje) is een Functioneel ontwerp, waarin je in tekst beschrijft wat je wilt gaan doen. Dat werkt veel beter als gelijk tabellen gaan tekenen. Als je de opdracht omschrijft als: "Ik wil kunnen vastleggen wanneer ik een nieuwe entry in een bepaalde wiki heb aangemaakt of bewerkt, en welke acties ik daarvoor heb ondernomen" dan zou je op basis daarvan uitkomen op wat ik hierboven geschetst heb. Maar ik weet dus niet of je zoiets zoekt.

 

[klad]

Hallo Michel,

Bedankt voor de reactie.
Ik heb je reactie een aantal keer doorgenomen, maar (zoals ik al vreesde) heb ik nog steeds moeite om de materie goed te begrijpen; waarschijnlijk te vaak met Excel gewerkt waar alles meer op één niveau zit. Het is dat Excel niet goed met afbeeldingen en blokken tekst werkt; anders kwam ik met sorteren en filteren al een eind in de buurt.
Ik was eerst begonnen met het beschrijven van wat ik precies wil, maar ik kreeg het niet goed uitgelegd. Vandaar dat ik heb geprobeerd mijn wensen in een schema samen te vatten, in de hoop dat het hiermee voor anderen ook duidelijk werd.
Als ik het goed begrijp kan ik het beste verschillende (losse) tabellen maken voor de status/bijdrage/bestemming en acties om ze dan in een formulier te gebruiken. Maar ik weet niet goed wat je bedoelt met hoofdtabel
Ik heb het eerst met een aantal voorbeeldtemplates geprobeerd, maar ik vond het moeilijk om mijn informatie hierin onder te brengen. Heb ik een template over het hoofd gezien die relatief weinig aanpassingen nodig heeft ?

Mvg,
Katrien

 

[OctaFish]

Er zijn vast sjablonen die ongeveer doen wat je wilt, maar die zul je toch ook moeten aanpassen. Dus zelf bouwen is dan wellicht handiger. Als je wat( of een deel) in Excel hebt gemaakt, kun je dat best als basis gebruiken. Zo kun je de Excel tabel gelijk als Hoofdtabel beschouwen. Heb je die ook . Bij het om/beschrijven van je ontwerp, moet je in Access denken in Gegevensstromen. Je wilt iets vastleggen, en wat is dat precies? En welke gegevens heb je daar voor nodig?

Voorbeeldje. Bij een webwinkel denk je bij gegevensstromen niet aan Klanten of producten, want dat zijn min of meer vaste 'eenheden'. Je denkt dan dus aan: wat doet de winkel? De winkel verkoopt artikelen. Wat gebeurt er bij verkoop? Je verkoopt een artikel, met als gevolg dat de voorraad daalt, en als gevolg daarvan moet je artikelen bestellen. Je hebt dus twee grote gegevensstromen: Verkoop en Inkoop. Op die twee poten draait (in grove lijnen) de winkel. Geen voorraad, geen verkoop!
Uiteraard heb je om iets te verkopen klanten nodig, en artikelen. Dat zijn dus je bronbestanden. Elke klant kan meerdere bestellingen plaatsen, en elk artikel kan meerdere keren verkocht worden. En daaraan herken je ook gelijk het verschil tussen een (wat ik dan noem) stamtabellen en gegevenstabellen. De gegevenstabel registreert per definitie unieke records, die dus maar één keer voor mogen komen. Elke verkooptransactie is uniek, elke inkoopactie ook. Stamtabellen registreren ook unieke records (elke klant uiteraard uniek) maar deze tabellen fungeren als invoer voor de hoofdtabellen.
Uiteindelijk bepalen de hoofdtabellen de werking van de organisatie, en nooit de stamtabellen. Het boeit de belasting niet hoeveel klanten je registreert, of hoeveel artikelen je kunt verkopen. Het uiteindelijk om hoeveel artikelen je hebt verkocht. En ingekocht.

Ik hoop dat dit voorbeeldje wat duidelijker maakt wat het onderscheid is tussen de tabellen. Technisch gezien zijn ze uiteraard identiek, maar tabellen voor keuzelijsten zijn dus per definitie bedoeld om als invoer te werken voor je hoofdtabel. In jouw geval wordt dat een tabel waarin je vastlegt welke activiteiten je hebt uitgevoerd.

 

[klad]

Ik heb geprobeerd een nieuwe basis te maken.
Hiervoor heb ik dus de bronbestanden gemaakt: Afbeeldingen, Acties, Status, type bijdrage en bestemming. Deze kunnen dan als keuze-invoer in de hoofdtabel worden gebruikt.

In de hoofdtabel plaats ik dan een "opzoeken en relatie" veld voor alle info die ik wil weergeven ?

Een nieuwe activiteit in de hoofdtabel wordt dan bv.:
- uniek nr.
- Datum
- Status (vb: suggestie; uit bronbestand Status)
- Type bijdrage (vb: nieuw artikel; uit bronbestand Bijdrage)
- Bestemming (vb: Wiki NL; uit bronbestand bestemming)
- Hyperlink (naar online lokatie artikel WIKI NL)
- Fotonr. (uit bronbestand Afbeeldingen)
- Onderwerp (uit bronbestand Afbeeldingen)
- Keywords (uit bronbestand Afbeeldingen)
- De afbeelding (foto)
- Pad PC (uit bronbestand Afbeeldingen)
- Acties (vb.: Tekst maken; uit bronbestand Acties)

Dus, mijn "activiteit" is elke nieuwe link die wordt gemaakt/voorbereid, elke link is een nieuw record met een verband naar een afbeelding op mijn PC en eventueel nog te ondernemen acties (bronbestanden). Maar kan ik in de praktijk dan ook een foto gelijk als nieuw record invoeren, of moet deze altijd eerst worden aangemaakt (in bronbestand Afbeeldingen) vóórdat ik het in de hoofdtabel kan gaan gebruiken ?

In bijlage stuur ik de eerste basis die ik heb geprobeerd te maken, ik hoop dat dit zo de bedoeling is ??
Alleen snap ik nog steeds niet hoe ik ervoor kan zorgen dat als ik vb. foto nr. 1 kies dan automatisch alle andere velden van foto 1 worden overgenomen.
En een tweede probleem heb ik bij het linken naar een Word-document in het geval dat Actie = "Tekst maken". Een bronbestand met keuze-velden is hierbij geen optie; ik heb hier vooraf geen lijst van en deze wordt in de loop van de tijd toch alleen maar onoverzichtelijk.

Mvg,
KatrienBekijk bijlage Wiki-test1.zip

 

[OctaFish]

Hoi Katrien, ik heb er nog niet naar gekeken, maar je opzet klinkt goed. Volgens mij heb je het aardig begrepen :thumb:. Al vermoed ik dat je keuzelijsten in je tabel hebt gemaakt, en dat zou ik dan weer niet doen. Maar daar kom ik vanavond nog wel op terug!

 

[klad]

Je vermoeden klopt, ik dacht dat dat de bedoeling was.. (blond)
Maar geeft niet, ik wacht rustig af.

 

[OctaFish]

Je bent in de verleidelijke verlokkingen van de Microsoft Sirens gevallen. Heeft niks met haarkleur te maken

 

[OctaFish]

Ok, hier dan het oordeel van de Rotterdamse jury . Ik heb wel een paar opmerkingen op je eerste ontwerp, al ben je niet slecht begonnen. Maar je maakt een paar beginnersfoutjes. Ik heb al gezegd dat je beter geen keuzelijsten in tabellen kunt gebruiken (wat je inderdaad had gedaan). De redenen daarvoor kun je overigens in de cursus teruglezen die in de handleiding sectie staat. Dus daar ga ik je nu niet mee lastig vallen. Wat meer? Belangrijkste fout: je gebruikt in je hoofdtabel meerdere velden die uit dezelfde tabel komen. Namelijk de tabel Afbeeldingen. En dat is niet handig. Tabellen die als opzoektabel fungeren, zoals de tabel Afbeeldingen, koppel je op basis van het sleutelveld aan je hoofdtabel. Omdat je Access de sleutels hebt laten maken, heten alle sleutelvelden ID wat wel mag, maar niet handig is. Beter kun je die velden een logische naam geven, zoals AfbeeldingID. Die koppel je in het venster <Relaties> dan aan de tabel [Hoofdtabel] op basis van de velden [AfbeeldingID] en [Fotonr]. Dank zij die relatie, en het feit dat je in de tabel Afbeelding alle fotogegevens zoals [onderwerp, [pad pc] etc al hebt ingevuld, hoef je ze in de Hoofdtabel niet meer in te vullen. Kortom: alle velden die je uit [Afbeelding] haalt, kunnen weg behalve [Fotonr].

Maar kan ik in de praktijk dan ook een foto gelijk als nieuw record invoeren, of moet deze altijd eerst worden aangemaakt (in bronbestand Afbeeldingen) vóórdat ik het in de hoofdtabel kan gaan gebruiken?

Dat is juist het mooie van keuzelijsten op formulieren: dat gaat perfect! Stel dat je inderdaad een nieuwe activiteit invoert, en daar hoort een nieuwe foto (of actie, of status) bij die je nog niet hebt ingevoerd. Geen probleem: keuzelijsten hebben een gebeurtenis <Bij niet in lijst> die ervoor zorgt dat ofwel het nieuwe gegeven wordt toegevoegd aan de juiste tabel (status, actie) ofwel een formulier opent waarin je het nieuwe object invoert en daarna verder gaat (afbeelding). Dus dat is helemaal al geregeld in het programma!
wat minder handig is, is het veld Bijlage dat je nu gebruikt voor je foto's. Dat kan wel, maar de database wordt daar ongelooflijk snel heel erg groot van. En voor je het weet zit je aan de maximum grootte, en knalt de boel uit elkaar. Wat we dan ook meestal doen, is een padverwijzing opnemen naar een map met de fotobestanden. Die sla je dus op buiten de database. Als je die map in dezelfde map als de database maakt, dan kun je heel simpel verwijzen naar de bestanden, en als je later de db verplaatst, dan blijft alles gewoon werken. Maar foto's dus niet opslaan in de db!
Hierbij een versie die ik een beetje heb opgeschoond dus. Je had nog geen formulier gemaakt (heel verstandig, eerst de basis goed) dus dat is de volgende stap! Als je tenminste alle gegevens nu kwijt kunt.

 

[klad]

Bedankt dat je nog zo laat voor mij aan de slag bent gegaan met mijn eerste proefstuk. Het is voor mij inmiddels een beetje laat geworden; mijn ogen zien dubbel van het turen naar alle tabelletjes...
Ik hoop morgenavond tijd vrij te kunnen maken, en anders begin ik zaterdag weer met een frisse blik aan de 'opgeschoonde' versie.
En inderdaad, het leek me nog niet erg zinvol om al te ver door te gaan. Ik had al zo'n vermoeden dat ik ergens op een verkeerd spoor zat. Het is al fijn om te weten dat het programma bij compleet nieuwe informatie de benodigde formulieren kan openen (Nice !).

Over de foto's moet ik nog even nadenken. Ik vind het wel erg fijn om een afbeelding ook echt te zien; veel van mijn onderwerpen lijken soms erg op elkaar. Dit is o.a. waarom het in Excel niet prettig werkte.
Daarnaast heb ik al mijn bestanden vrij gestructureerd op mijn PC, met een automatische backup naar een NAS in mijn netwerk. Deze wordt dan eens per maand nog eens op een losse externe HD gezet die ik buitenshuis bewaar.
Als ik alle foto's die ik in de database wil gebruiken moet kopiëren naar de map voor de database krijg ik nóg meer kopieën, neemt het veel schijfruimte in beslag, en gaat het maken van backups nóg langer duren.
Zou het een oplossing zijn om de afbeeldingen in de database-map kleiner te maken, bv. een max. formaat van 200 x 200 px zodat ik niet snel in de problemen kom ?

Mvg,
Katrien

 

[OctaFish]

Over de foto's moet ik nog even nadenken. Ik vind het wel erg fijn om een afbeelding ook echt te zien; veel van mijn onderwerpen lijken soms erg op elkaar. Dit is o.a. waarom het in Excel niet prettig werkte.

Je gaat me nu een zeur vinden ("dat heeft u al 6 keer gezegd" ) maar dat zou dus in je ontwerp hebben moeten staan . Want dat is in Access helemaal geen probleem! Je kunt prima foto's extern opslaan, en ze op het formulier laten zien wanneer je ze nodig hebt. Kortom: dat is de reden dat je voor dit soort dingen beter Access kunt gebruiken dan Excel. Eigenlijk leg je in een Plan dus vast wat je wilt doen, en welke eisen je hebt, en daarna ga je kijken welk programma dat het beste kan doen. En daarna ga je bouwen. Wat de meeste mensen doen is: ik heb Access (of Excel), hoe kan ik mijn vraag daarin maken? Terwijl het pakket dus uit het "Programma van Eisen" zou moeten rollen, en niet andersom!
Maar je afbeeldingen is dus verder helemaal geen probleem, ook niet als je de foto's elders opslaat.

 

[klad]

Sorry over de verwarring met de afbeeldingen, ik zal het wel niet goed hebben uitgelegd in het Excel-schema. Daar had ik bij Afbeelding een pijl naar 'foto'. Hiermee bedoelde ik dus dat ik daar ook een echte foto wil zien.

Bij de bronbestanden heb ik 2 aanpassingen:
- Bij Bestemming heb ik nog een Titel toegevoegd (naam van het Wiki-artikel).
- Ik denk dat de hyperlink beter verplaatst kan worden van 'Afbeeldingen' naar 'Bestemming'. Eén afbeelding kan op meerdere bestemmingen (elk met een eigen hyperlink) terecht komen; maar bij een bestemming wordt altijd maar 1 afbeelding gebruikt.

En keuzelijsten kan ik dus beter niet in de tabellen gebruiken, maar alleen bij formulieren? Maar hoe moet ik dan de tabellen opstellen?

Dit is hoe ik denk dat mijn 'werkschema' er uit komt te zien:

Ik zie een hiaat op Wiki NL waarvoor ik een afbeelding heb en tekst kan bijdragen. Dan maak ik in de hoofdtabel:

1. nieuw volgnr.
2. Datum
3. Status: Suggestie
4. Bijdrage: Afbeelding + tekst
5. Bestemming: Wiki NL
6. Hyperlink: www.wiki.nl/artikel
7. Titel: titel van het online artikel
==
Hier wil ik een bestaande afbeelding uit mijn archief toevoegen. Als het een nieuwe toevoeging is komt een popup-venster waar ik de volgende gegevens kan invullen:
7. Foto nr.: AfbeeldingID
8. Afbeelding: foto van betreffend artikel
9. Naam afbeelding
10. Pad (op mijn computer)
11. Onderwerp
12. Categorie
13. Keywords
Als de Afbeelding al eerder is aangemaakt kan ik dan hier alleen de Afbeelding-ID invullen? Maar hoe gaat dit in de praktijk eruitzien zodat ik zeker de correcte afbeelding gebruik. Komt hier ook een popup venster waar ik uit kan selecteren, of kan ik een zoekfunctie op naam of keywords inbouwen ?
==
14. Acties: Vinkje aan bij Tekst maken en bij Publiceren

Zodra ik effectief aan de tekst ga werken gaat de status van 'Suggestie' naar 'In behandeling'.
Is de tekst klaar, dan wordt deze bij Acties uitgevinkt, 'Publiceren' blijft nog aangevinkt.

Nadat ik de tekst en afbeelding op de Wiki NL-site heb gepubliceerd gaat het vinkje bij Actie 'Publiceren' uit en Status gaat naar 'Afgehandeld'.


Tussendoor wil ik op diverse manieren gegevens uit de database kunnen halen zodat ik weet waar aan gewerkt wordt; of wat er al eerder met een bepaalde afbeelding is gebeurd.
Voorbeelden van 'zoekopdrachten':

- Lijst van alles waar de status 'In behandeling' is.
- Lijst van alles waarbij actie 'Foto maken' is.
- Lijst van alle bestemmingen waarbij Afbeelding nr. X is gebruikt.

Hoe kan ik deze zoekopdrachten het beste samenstellen ?

Mvg,
Katrien

 

[OctaFish]

- Ik denk dat de hyperlink beter verplaatst kan worden van 'Afbeeldingen' naar 'Bestemming'. Eén afbeelding kan op meerdere bestemmingen (elk met een eigen hyperlink) terecht komen; maar bij een bestemming wordt altijd maar 1 afbeelding gebruikt.

Zie je helemaal goed; in dit geval is de tabel [Afbeelding] een brontabel voor [Bestemming]. In een tabel moet je (vind ik dus) altijd de echte waarden terug kunnen zien. Dus wat er is ingevoerd en opgeslagen. Gebruikers (of je dat nu alleen zelf bent, of met meerdere personen werkt) hebben in beginsel niks in een tabel te zoeken. Alles wat je doet in je database (invoeren, muteren, raadplegen) doe je op formulieren of met rapporten. Wat er in de tabellen zelf staat, boeit dus eigenlijk voor geen meter. Zolang het maar klopt .

Als de Afbeelding al eerder is aangemaakt kan ik dan hier alleen de Afbeelding-ID invullen? Maar hoe gaat dit in de praktijk eruitzien zodat ik zeker de correcte afbeelding gebruik. Komt hier ook een popup venster waar ik uit kan selecteren, of kan ik een zoekfunctie op naam of keywords inbouwen ?

Hier zit een 'probleempje' waar ik niet gelijk een antwoord op heb. Bij normale (tekst)gegevens is het antwoord heel simpel: bestaande items zoek je op in de bestaande tabel met een keuzelijst, en als je een nieuwe waarde intypt in de keuzelijst (en daarmee de actie NotInList activeert) ga je naar het formulier van die tabel, en voeg je de nieuwe waarde verder toe. Probleem opgelost. Bij afbeeldingen kan dit op dezelfde manier worden opgelost, maar ik kan mij heel goed voorstellen dat je bij een bepaald artikel visueel wilt kunnen zoeken, oftewel: je zult misschien willen bladeren door de geregistreerde afbeeldingen. En dan verandert de zoekmethode aanzienlijk, want zoeken op plaatjes kan niet met een keuzelijst, dan moet je gaan zoeken met een formulier. Maar dan is het nog steeds wel te doen.

Puntje 14: die snap ik nog niet helemaal. Ik zie geen meerwaarde in extra selectievakjes. En al helemaal niet in combinatie met keuzelijsten. Ik zou je voorstellen om één keuzelijst te maken waarin je de verschillende statussen van een bijdrage vastlegt, en die je dan verandert al naargelang de fase waarin de bijdrage zit. Dít kan dan eventueel wél een keuzelijst zijn die je in de tabel maakt. Want het is een keuzelijst met een aantal vooraf vastgestelde opties, waar je niet zo snel in gaat muteren, iets wat bij tabellen vaak wel het geval is. Al mag je zo'n keuzelijst best apart in een tabel maken.

Wat je laatste vraag betreft: die is heel simpel te realiseren als je met één keuzelijst met statussen werkt. Je filtert het formulier dan op één of meer van de statussen.

 

[klad]

Puntje 14: die snap ik nog niet helemaal. Ik zie geen meerwaarde in extra selectievakjes. En al helemaal niet in combinatie met keuzelijsten. Ik zou je voorstellen om één keuzelijst te maken waarin je de verschillende statussen van een bijdrage vastlegt, en die je dan verandert al naargelang de fase waarin de bijdrage zit.

Het idee hierachter is dat ik op een gegeven moment kan opvragen waar ik nog foto's van moet maken/bewerken of tekst opstellen. Hier gaat soms best wat tijd overheen. Ik heb iemand die af en toe langskomt om alle foto's te maken, het is dus handig snel een lijst te hebben van wat er nog moet gebeuren. Maar misschien zie ik een andere/betere manier hiervoor over het hoofd ?

Ik heb al gezegd dat je beter geen keuzelijsten in tabellen kunt gebruiken (wat je inderdaad had gedaan). De redenen daarvoor kun je overigens in de cursus teruglezen die in de handleiding sectie staat.

Hier ben ik nog een beetje in de war. Als ik het stukje in de handleiding goed begrijp kan ik wel keuzelijsten (Wizard opzoeken) gebruiken in brontabellen waar alleen een beperkte (vaste) selectie mogelijk is ? Net zoals in het voorbeeld (Man/vrouw) heeft bij mij de tabel 'Status' maar een beperkt aantal mogelijkheden. En bij mijn tabel 'Afbeeldingen' kan ik het beter niet gebruiken bij het veld 'Keywords' omdat deze lijst te lang zal worden ? Of heb ik het (nog) niet goed begrepen ?

Ik ben vandaag nog wat aan de slag gegaan, en ook nog een aantal hoofdstukken van de handleiding doorgenomen :thumb:; maar als ik zo wat verder lees ben ik bang dat het voor mij wat te hoog gegrepen is. Ik heb nogal wat moeite met het omzetten van de theorie naar de praktijk; en om de praktijkvoorbeelden om te zetten naar mijn eigen situatie. Ik heb nu brontabellen gedefinieerd waarin wordt bepaald welke gegevens moeten worden verzameld. Maar ik zie niet goed hoe ik deze informatie verder moet verwerken. Moet ik nu formulieren of rapporten ontwerpen waarin de gegevens straks worden ingevoerd ? En moet ik voor elke 'vraag' die ik uit het programma wil halen een apart rapport maken ?

De materie is een stuk lastiger dan ik had gehoopt. Bij de voorbeeldsjablonen zitten wel mooie formulieren; maar het lukt me nog steeds niet eentje als oefening te bewerken zonder dat ik alles verknoei, laat staan dat ik een hele nieuwe zelf kan aanmaken.
Ik waardeer het ontzettend dat u probeert mij de beginselen bij te brengen, maar ik ben een beetje bang dat het compleet zelf bouwen te moeilijk zal blijken. En al die tijd staat het project waar ik het eigenlijk voor doe helemaal stil. En dat vind ik best wel jammer; als ik eenmaal een goede basis had zou ik dit programma wel graag willen gebruiken. Wat ik er van heb gezien in de voorbeeldsjablonen lijkt het erg fijn om er mee te werken; alleen het ontwerpen valt (tot nu toe) erg tegen :shocked:

 

[OctaFish]

Hier ben ik nog een beetje in de war. ... Of heb ik het (nog) niet goed begrepen ?

Volgens mij heb je het nu prima begrepen . Je vertolkt in ieder geval mijn opvatting perfect! Neemt niet weg dat je het best anders mag aanpakken als je dat wilt, want technisch gezien is het niet fout of zo. Alleen kom je volgens mij vroeg of laat in de problemen als je tabellen als keuzelijsten gebruikt in een andere tabel. Zoals ik al zei: in een tabel wil je de opbeslagen waarde zien. Als die opgeslagen waarde uit een keuzelijst komt: prima!
Ik snap overigens dat je door het bos de bomen niet meer ziet, want Access is geen eenvoudig programma om te leren. Dit in tegenstelling tot Word en Excel, waarmee je veel sneller aan de slag kan. Bij Microsoft leeft (volgens mij) de opvatting dat als je de knopjes kent, je het programma ook kent, maar dat werkt natuurlijk niet zo.
Ik zag in je profiel dat je in Spijkenisse woont, en dat is voor mij niet zo heel ver weg (Rotjeknor), dus als je dat wilt, kan ik je wel een avondje op weg helpen met de meest elementaire zaken te bouwen. Dan heb je een basis waar je meer vooruit kan.