Meerdere tabelkolommen met zoekwaarde tonen op formulier

Status
Niet open voor verdere reacties.
Hallo,

even je DB schema bekeken en alvast de volgende fouten gevonden: werkzaamheden en klanten worden via de koppeltabel1 aan elkaar gebonden, en dan nog eens rechtstreeks naar de projectentabel. De rechtstreekse koppelingen zijn er wat teveel aan. Verder wil je teveel in één koppeltabel samen zetten. Ik zou ook voor de status (on hold/geannuleerd/gereed) één veld kiezen waar je de verschillende waarden via een combo box kan kiezen. Een project kan toch geen meerdere statussen tegelijk hebben?

Het volgend schema geeft een voorbeeld (niet alle velden zijn overgenomen) van de gewijzigde structuur:
ProjectenWerkzaamheden.jpg
 
Dus als ik het goed begrijp, moet ik geen relaties buiten de koppeltabel om maken? Hoe krijg ik dan die betreffende gegevens in de tabel (bv. ordernummer en klantnaam in de tabel werkzaamheden)? En moet ik de koppeltabel opdelen in meerdere koppeltabellen? Hoe gaat dit precies?

De status ga ik denk ik op jouw manier oplossen. Het is idd niet mogelijk meerdere statussen op een order te hebben :thumb:

Bedankt voor het meedenken!
 
Het volgend schema geeft een voorbeeld (niet alle velden zijn overgenomen) van de gewijzigde structuur:
Bekijk bijlage 348706

Wat zijn nu precies één-op-veel relaties en wat zijn de veel-op-veel relaties?

En hoe krijg ik nu het projectnummer en de klantnaam in mijn overzicht met werkzaamheden? (Ik zal ze dus weer gaan opzoeken in de tabellen "Projecten"en "Klanten", maar dan ga ik weer buiten de koppeltabellen om.
 
Laatst bewerkt:
een veel op veel relatie wordt altijd gelegd via 2 1 op veel relaties. In het voorbeeld: 1 klant kan veel verschillende projecten lopende hebben en 1 project kan meerdere klanten hebben. Dat is een veel op veel relatie. Dus is de tabel projectenklanten gemaakt met 2 één op veel relaties: 1 Klant -> projectenklanten <- Projecten. Dit is zo in het voorbeeld gedaan omdat dit in jou database ook via de koppeltabel was. Als één project slechts één klant kan hebben dan is die koppeltabel niet nodig en kan je het klantID rechtstreeks in je projectentabel opnemen in een één op veel relatie van klant -> projecten.

Idem voor projectwerkzaamheden <=> werknemers. Aan één werkzaamheid kunnen meerdere werknemers samenwerken en één werknemer kan aan meerdere werkzaamheden werken. Vandaar de koppeltabel WerknemesProjectwerk.
Hoe kan je die tonen? De tabellen worden weer aan elkaar gesmeed in queries: als er een veel op veel relatie is dan neem je de drie tabellen bv. werknemers, projectwerkzaamheden en WerknemesProjectwerk op in één query. Als je de relaties goed gelegd hebt en het QBE (Query By Example) venster gebruikt zullen de relaties ook in het queryvenster automatisch goed liggen. Het enige dat je dan nog hoeft te doen is de velden die je wenst te tonen in je query op te nemen.

In een formulier kan dit via een hoofd met subformulier worden weergegeven, of je kan kiezen voor linked forms.
 
Bedankt voor je antwoord.

Ik ben me er van bewust wat een veel-op-veel is en hoe die gemaakt wordt, maar ik ben in jouw overzicht even kwijt wat ik in de koppeltabellen aanduid als primaire sleutel. Mijns inziens volg ik nu jouw voorbeeld, maar ik krijg niet de data goed voor elkaar. Mijn relaties zien er nu als volgt uit:

relaties.png

Verder zal ik even uitzoeken wat het QBE is en hoe het mij hierin gaat helpen :)
 
Ja daar was ik gauw achter. Maar betekent dit nu dat ik me minder zorgen moet maken om het projectnummer en de klantnaam in de tabel "werkzaamheden" te krijgen, maar dat dit zich oplost in het formulier?
 
Wat me nog steeds niet lukt is het weergeven van Projectnummer en klantnaam in mijn overzicht van de werkzaamheden... Hoe krijg ik dit voor elkaar? De rest is op Noella's manier opgelost...
 
ik vermoed dat dit toch een kwestie is van de juiste SQl op te bouwen. kan je de sql instructie die je nu gebruikt voor het overzicht van werkzaamheden posten? En wat wil je precies zien? En is dit in een query of in een rapport?
 
Bij deze het testdocument.

Wat ik graag wil zien in het subformulier "werkzaamheden" is de bijbehorende klantnaam en projectnummer. De bedoeling is een overzicht van uit te voeren taken per werknemer.
 

Bijlagen

  • Testdocument3.zip
    53,3 KB · Weergaven: 32
Laatst bewerkt:
Geprobeerd om vanaf 0 de relaties op de bouwen, exact volgens het voorbeeld van Noella. Wanneer ik de koppeling wil maken tussen projectwerkzaamheden en werknemers, stuit ik op het volgende:

Lastig.png

Gaat hier iets mis?
 
je hebt blijkbaar in de tabelprojectwerkzaamheden en werknemersprojectwerk een dubbele primaire sleutel gelegd (= index op 2 velden). Verwijder het veld PW_project uit de primaire sleutel. Idem voor het veld WPW_projectwerkzaamheid, dit is ook geen deel van de primaire sleutel, maar de foreign key naar de tabel ProjectWerkzaamheden.PW_ID
 
FYI: een primaier sleutel bestaat uit het minimale aantal velden dat nodig is om één record te identificeren. Die sleutel mag best uit meerdere velden bestaan, maar in jouw geval heb je een Autonummerveld, en dat is dus op zichzelf al genoeg om het record te identiferen. Dan volstaat dus één veld als sleutel. Dat is ook een stuk handiger in de koppelingen.
 
Ik ben het spoor en beetje bijster. Ik heb nu voor elke veel-op-veel relatie een koppeltabel gemaakt en dat werkt naar mijn idee best goed. Ik krijg ook data van de "naastliggende" tabellen goed in beeld. Even een schematische weergave:

Tabel1 - Koppeltabel - Tabel2 - Koppeltabel - Tabel3

1. Gegevens van Tabel1 krijg ik in Tabel2 en vice versa
2. Gegevens van Tabel2 krijg ik in Tabel3 en vice versa
3. Wat ik graag wil: Gegevens uit Tabel1 (in dit geval "Klanten") in Tabel3 ("Werkzaamheden") weergeven. Dit is wat me niet lukt.

Als het gewoon mogelijk is dit alleen in een formulier voor elkaar te krijgen (dus gekoppelde gegevens uit "Klanten" in het formulier "Werkzaamheden") word ik ook heel blij. Probleem is nu, dat ik het overzicht een beetje kwijt ben en dus niet weet waar ik moet zoeken of naar moet verwijzen. Verder begint de autist in mij continu opnieuw met "een schone lei" om vervolgens weer tegen hetzelfde aan te lopen. Daar schiet ik dus niks mee op.

Huidige stand van zaken:
relaties1406.png

Rood omkaderd het probleemkind. Ik verwijs naar "Kla_bedrijfsnaam" uit de tabel klanten. Dit slikt hij niet. Ook al geprobeerd naar "Pro_Klantnaam" geprobeerd te verwijzen, maar dat gaat ook niet. Dat zal dan mijn theorie hierboven over de naastliggende tabellen dus ook weer ontkrachten...
 
Je koppeltabellen hebben nu een driedubbele primaire sleutel? Enige reden waarom je dat zou doen? Normaal heb je daar een enkelvoudige primaire sleutel en 2 vreemde sleutels (foreign keys). Je kan je beschermen door een unieke, dubbele index te leggen op de vreemde sleutelvelden.
 
Ik snap wat je bedoelt, dit is inderdaad een beetje onlogisch nu ik er zo over nadenk. Kan de "eigen" primaire sleutel wel verwijderen zoals ik het nu bekijk. Echter los ik daar toch niet het probleem mee op wat hierboven is beschreven?
 
elke tabel moet een "eigen" primaire sleutel hebben, die is de belangrijkste. Als je dat niet doet is je tabel als een hoop gegevens opgebouwd (heap) zonder toegangssleutel. Hou de eigen primaire sleutel, maar verwijder de 2 foreign key velden uit de combinatie en maak voor deze velden een eigen, gecombineerde unieke index. Maar geen primaire sleutel.
 
ProjectWerkzaamheden kan gewoon met één sleutelveld af (je Autonummerveld). Als je mijn bijdragen niet leest (#33) dan wil ik best afhaken, want dan vind ik het zonde van mijn tijd :).
Volgende probleem: de velden Preo_klantnaam en PW_KLantnaam moeten gewoon weg, die horen niet in die tabellen. Net als PW_Projectnummer. Haal alle overbodige velden weg uit je tabellen, en je komt een stuk verder.
 
Ik zal kijken of ik vandaag nog tijd heb om een voorbeeld in een formulier te maken. Maar is nu tijd voor het betalend werk.
 
Dat wordt zeer gewaardeerd :)

Hierbij de laatste versie. Nog wel met 3 primaire sleutels in de koppeltabellen, maar dat is denk ik niet een probleem...
 

Bijlagen

  • Planning14062020.zip
    77,5 KB · Weergaven: 30
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan