Plaatjes helpen wel om een vraag te verduidelijken, maar een database doet dat nog veel beter, omdat we dan echt iets kunnen doen. Allereerst wat algemene tips. Je wilt in tabellen een opzoekveld maken gebaseerd op andere tabellen. Slecht idee. Je bent een nieuwe Access gebruiker, gaf je zelf al aan, en dan is het begrijpelijk dat je vertrouwt op de mogelijkheden die Microsoft inbouwt in het pakket. Zou ik zelf eerlijk gezegd ook doen. Maar neem van mij aan: doe dat niet; bij Microsoft lopen enorme sukkels rond, die waarschijnlijk te goede connecties hebben met Bill Gates zodat ze niet ontslagen mogen worden, en om ze toch wat om handen te geven, mogen ze van de baas in Access ontwikkelen. Met als resultaat dat er de laatste jaren enorme stupiede opties in het pakket zijn verschenen die totaal onzinnig zijn. De keuzelijsten in een tabel (op basis van een tabel) is daarvan niet eens de grootste stommiteit, maar ik zal je dat lijstje verder besparen.
Maar de essentie is dus: gebruik nooit tabellen in een keuzelijst in een andere tabel. Keuzelijsten in een tabel baseer je hooguit op een lijst met waarden. Je gebruikt uiteraard wel keuzelijsten op basis van tabellen, maar die maak je op een formulier, niet in een tabel. In tabellen moet je te allen tijde de echte waarden kunnen zien die je opslaat. Met keuzelijsten die je op een tabel baseert gebeurt dat niet (altijd). In je afbeeldingen zie ik dat je die opzoektabel ook al gebruikt voor [Nemer/Klant]. Mijn advies is dus simpel: zo snel mogelijk omzetten naar een gewoon tekstveld!
Daarnaast constateer ik een aantal overbodige velden, die niet nodig zijn omdat ze dubbele waarden opleveren. Zo heb je een veld [VH_Datum], een veld [VH_Dag] en een veld [VH_Tijd]. Je hebt alleen de eerste nodig die je dan vult met de functie Now(). Stel je voor dat je in het veld [VH_Datum] de huidige datum invult, toevallig een Woensdag. Wat vul je dan in het veld [VH_Dag] in? Maandag? Donderdag? Lijkt mij dat je daar óók de dag van de huidige datum wilt invullen, dus Woensdag. Maar dat hóeft dus niet; je kunt elke dag van de week invullen. Lijkt mij erg verwarrend, en nogmaals: nergens voor nodig want je hébt de datum al ingevuld. En dat geldt dus ook voor de tijd.
Voor retour registraties gebruik je zelfs 5 velden waarvan ik zo niet eens kan bedenken waar die allemaal voor zijn!
Wat je oorspronkelijke vraag betreft: ik begin langzaam een idee te krijgen wat je eigenlijk probeert te vragen. In eerste instantie dacht ik dat je de tabellen [Graafmachines] en [Aanhangwagens] in één nieuwe tabel wilde zetten zodat je met die tabel (laten we hem [Voertuigen] noemen) verder kon werken. Nu lijkt het er op dat je de tabellen los wilt houden, maar in de tabel [Verhuur] samen wilt zien zodat je de verhuurde apparaten in één veld kunt zetten. En dat lukt dus niet, zoals je al hebt geconstateerd.
Ook hier is het advies simpel: hardware hoort niet in losse tabellen te staan, maar bij voorkeur in één tabel. Dat is niet altijd mogelijk; een voertuig heeft andere eigenschappen als een telefoon bijvoorbeeld. Een tabel waarin je zowel voertuigen als telefoons wilt opslaan zou dan velden moeten krijgen als: ApparaatID, Naam, Merk, Type, Aanschafprijs, Leverancier etc. Al deze aspecten zijn zowel bij een auto als bij een telefoon hetzelfde. Maar bij een voertuig wil je wellicht het aantal zitplaatsen vastleggen, het aantal PK's, het soort brandstof, en bij een telefoon het SIMkaart nummer, de provider en het telefoonnummer. Dat zijn apparaatspecifieke gegevens die bij de één wel nodig zijn en bij de ander niet.
Daarom zie je vaak dat hardware toch in verschillende tabellen is opgesplitst. Persoonlijk hou ik wel van een systeem waarin alle objecten in één tabel worden vastgelegd, en de objectspecifieke eigenschappen in gekoppelde tabellen. Zo kun je in de tabel [Objecten] een veld [Type] opnemen, op basis waarvan je dan de juiste tabel kan invullen voor de objectspecifieke gegevens. Bij een voertuig kies je dan de categorie "Voertuig" en krijg je de subtabel [Voertuigdetails] te zien, en bij een telefoon kies je dan de categorie "Telecommunicatie" en krijg je de subtabel [Telecommunicatiedetails] om in te vullen.
Een goed ontworpen database heeft dus tabellen die zijn gebaseerd op objecten die gemeenschappelijke kenmerken hebben. Zoals ik in het voorbeeld hierboven al heb uitgelegd voor de tabel Objecten. Elk object is uniek en eenmalig, en heeft dezelfde kenmerken zoals een Naam, Leverancier, Aanschafdatum, Afschrijftermijn etc. Die gegevens komen dus in één tabel. Hetzelfde geldt ook voor personen; je kunt een tabel [Werknemers] hebben, maar daarin maak je geen onderscheid tussen een tabel voor Mannen en voor Vrouwen. Wél zul je in die tabel een veld [Geslacht] opnemen, zodat je dat onderscheid wel kunt vastleggen.
Bij objecten (dat speelt bij jou vermoed ik ook) zit nog een complicatie: soms vormt een samenstelling van twee of meer objecten één nieuw object. Bij voertuigregistratie kun je bijvoorbeeld een vrachtwagen uitrusten met een aanhangwagen, die dan tegelijkertijd op pad gaan en samen ook weer terugkomen. Leg je die twee los vast in de verhuurtabel? Is niet handig, want dan moet je ze ook apart inboeken en terugboeken. En misschien gaat er ook wel een heftruck mee, dan wordt het nog ingewikkelder. Voor dat soort situaties kun je boven de objecten nog een nieuwe tabel zetten: [Configuraties]. Hierin maak je dan een combinatie aan van verschillende objecten. In je verhuur registreer je dan de uitgifte van die configuratie, en niet meer van de losse onderdelen.
Ik hoop dat het zo wat duidelijker wordt wat wij van jou willen weten, en doe er dus een database bestand bij (wel zippen, want HelpMij accepteert geen access bestanden) dan kunnen we veel beter zien wat je tot nu toe hebt gemaakt.
