Hallo allemaal. Hoe los ik het volgende vraagstuk op. Er is een tabel met de velden: ID, straatnaam, huisnummer, plaats, opdrachtnummer en beschrijving. Dmv een formulier worden in de tabel in de loop der tijd records met adressen en opdrachtnummers etc. toegevoegd. Bepaalde adressen kunnen in de tabel meerdere keren voorkomen echter met een ander opdrachtnummer en bijbehorende beschrijving. De bedoeling is dat, mbv. een keuzelijst met invoervak één bepaald adres, bestaande uit straat, huisnummer en plaats, wordt geselecteerd. Aan de hand van dit gegeven moeten alle voorkomende opdrachten met beschrijving uit de tabel op dit adres worden gefilterd en in een (sub)forumlier worden gepresenteerd. Dus in het formulier staat het adres en daaronder oid. staat een lijst met historische opdrachtnummers en beschrijvingen. De keuzelijst is dmv VBA gelukt en is gebaseerd op een query waarbij ik de straatnaam oplopend heb kunnen sorteren. Sommige adressen komen dus meerdere keren voor. Ik weet geen oplossing voor het filteren en presenteren van de opdrachtnummers en beschrijvingen uit de tabel. Hoe kan ik het realiseren?
Access. Waarden van bij elkaar horende records verzamelen en tonen in een formulier.
- Onderwerp starter KPTPTT
- Startdatum
- Status
OctaFish
Verenigingslid
- Lid geworden
- 6 feb 2009
- Berichten
- 43.695
- Besturingssysteem
- Windows 10/MacOS
- Office versie
- Office 365
Je probleem wordt veroorzaakt doordat je tabel niet genormaliseerd is. Los dat op en je probleem is weg. Dat normaliseren bestaat er uit dat je de gegevens in je tabel gaat groeperen op gegevens die bij elkaar horen. Die zet je in een eigen tabel. Vervolgens koppel je de gesplitste gegevens weer aan elkaar met koppeltabellen, waar je vervolgens je formulier op baseert. In die formulieren kun je dan d.m.v. subformulieren de gegevens zien die je nu vraagt.
Als ik jouw tabel bekijk, zie ik op twee niveau's een probleem. Met het grootste te beginnen: je hebt dus nu twee groepen met gegevens die niets met elkaar te maken hebben, en die je dus moet splitsen.
Tabel Opdracht krijgt de velden: [OpdrachtID], [opdrachtnummer] en [beschrijving] (en nog wat extra velden vermoedelijk, want ik zie nergens een datumveld bijvoorbeeld, of een uitvoerder)
Tabel Adressen krijgt de velden: [AdresID], [straatnaam], [huisnummer] en [plaats]
Gebruikte normalisatieregel is hier: gegevens die niet afhankelijk zijn van de sleutel van de tabel, gaan naar een eigen tabel. De adresgegevens dus in dit geval.
De tabel Adressen bevat het tweede probleem: de straatnaam en plaatsnaam. Gebruikers zijn volledig bereid en in staat om een plaatsnaam op tig verschillende manieren in te voeren. Zelfs als je géén typefouten maakt, kun je al de teil in gaan met de plaatsnamen 's Gravenhage en Den Haag bijvoorbeeld. En dan heb ik het nog niet over straatnamen: "Burg. Oudlaan", "Burgemeester Oudlaan", "Burgermeerster Oudlaan" etc. Dus in de tabel Adressen ga je verder normaliseren. Nu ga je herhalende gegevens onderbrengen in een eigen tabel. Normalisatieregel 2: gegevens die gedeeltelijk afhankelijk zijn van de sleutel, breng je onder in een eigen tabel.
Dus normaal gesproken maak je een tabel met Plaatsnamen, en Straatnamen. In de tabel Straatnamen neem je dan een verwijzingsveld op naar de sleutel van de tabel Plaatsnamen. Ik mis bij jou hier overigens een veld met de postcode; lijkt mij niet onbelangrijk!
Ik zou hier dus eerst mee beginnen, en dan zal je zien dat je, als je de tabellen hebt gemaakt, je op basis van de koppeltabel (die heb je ook nodig) Opdracht_Adres twee soorten formulieren kan maken: één op basis van opdracht(gever), en één op basis van adres. In de ene zie je dan de gekoppelde adressen in het subformulier, in het andere de gekoppelde opdrachten.
Maar het begint dus bij een goede opzet van je database.
Als ik jouw tabel bekijk, zie ik op twee niveau's een probleem. Met het grootste te beginnen: je hebt dus nu twee groepen met gegevens die niets met elkaar te maken hebben, en die je dus moet splitsen.
Tabel Opdracht krijgt de velden: [OpdrachtID], [opdrachtnummer] en [beschrijving] (en nog wat extra velden vermoedelijk, want ik zie nergens een datumveld bijvoorbeeld, of een uitvoerder)
Tabel Adressen krijgt de velden: [AdresID], [straatnaam], [huisnummer] en [plaats]
Gebruikte normalisatieregel is hier: gegevens die niet afhankelijk zijn van de sleutel van de tabel, gaan naar een eigen tabel. De adresgegevens dus in dit geval.
De tabel Adressen bevat het tweede probleem: de straatnaam en plaatsnaam. Gebruikers zijn volledig bereid en in staat om een plaatsnaam op tig verschillende manieren in te voeren. Zelfs als je géén typefouten maakt, kun je al de teil in gaan met de plaatsnamen 's Gravenhage en Den Haag bijvoorbeeld. En dan heb ik het nog niet over straatnamen: "Burg. Oudlaan", "Burgemeester Oudlaan", "Burgermeerster Oudlaan" etc. Dus in de tabel Adressen ga je verder normaliseren. Nu ga je herhalende gegevens onderbrengen in een eigen tabel. Normalisatieregel 2: gegevens die gedeeltelijk afhankelijk zijn van de sleutel, breng je onder in een eigen tabel.
Dus normaal gesproken maak je een tabel met Plaatsnamen, en Straatnamen. In de tabel Straatnamen neem je dan een verwijzingsveld op naar de sleutel van de tabel Plaatsnamen. Ik mis bij jou hier overigens een veld met de postcode; lijkt mij niet onbelangrijk!
Ik zou hier dus eerst mee beginnen, en dan zal je zien dat je, als je de tabellen hebt gemaakt, je op basis van de koppeltabel (die heb je ook nodig) Opdracht_Adres twee soorten formulieren kan maken: één op basis van opdracht(gever), en één op basis van adres. In de ene zie je dan de gekoppelde adressen in het subformulier, in het andere de gekoppelde opdrachten.
Maar het begint dus bij een goede opzet van je database.
OctaFish
Verenigingslid
- Lid geworden
- 6 feb 2009
- Berichten
- 43.695
- Besturingssysteem
- Windows 10/MacOS
- Office versie
- Office 365
Met ombouwen moet je inderdaad heel voorzichtig te werk gaan. Sowieso maak je natuurlijk een kopie van het complete systeem waarin je gaat sleutelen. En ik maak dan vaak ook eerst kopieën van de tabellen en formulieren.
- Status
