Contactpersoon toewijzen aan bedrijf via subformulier

[Robbin R]

Ik ben nu al enigszins op weg naar een bruikbare database.

Hierin heb ik twee tabellen tblContactpersonen en tblBedrijven, die samenkomen in tblBedrijfsContactpersonen.

Ik heb tevens formulieren om contactpersonen en bedrijven toe te voegen. Nu wil ik graag in het formulier frmContactpersonen in het subformulier fsubBedrijfsContactpersonen de contactpersoon toewijzen aan een bedrijf.
Als ik echter op de pijl naar onderen klik en een bedrijf kies, dan krijg ik de volgende melding in de statusbalk:

'Kan geen record(s) toevoegen. De join-sleutel van de tabel tblBedrijfsContactpersonen komt niet voor in de recordset.'

Heeft iemand ervaring mee hoe je dit probleem kan oplossen.

In de bijlage zit de database in 2003 formaat.

 

[OctaFish]

Je maakt een kleine denkfout; je hebt een verkeerde query onder je formulier gehangen. Als je contactpersonen wilt koppelen aan een bedrijf, dan moet je records aanmaken in de tabel [tblBedrijfsContactpersonen]. Je zult dus het Subformulier moeten baseren op deze tabel, en je Hoofdformulier moeten koppelen aan de tabel [Contactpersonen]. Beide formulieren zijn dan gekoppeld op basis van het ContactPersoonID.

 

[Robbin R]

Maar het subformulier heeft nu als recordbron qryBedrijfsContactpersonen. Als ik in de query een wijziging doorvoer, dan wordt dit toch automatisch aangepast in de tblBedrijfsContactpersonen?

Het klopt wel wat je zegt, want als ik het aanpas naar tblBedrijfsContactpersonen, dan kan ik het inderdaad aanpassen. Alleen dan staan de keuze in de keuzelijst met invoervak niet meer op alfabetische volgorde (wat ik met de qryBedrijfsContactpersonen wel voor elkaar krijg).

 

[OctaFish]

Je moet de keuzelijsten ook los zien van de tabel die je als basis voor het formulier gebruikt. Als je de query [qryBedrijfsContactpersonen] bekijkt, zie je dat je het veld [ContacpersoonID] uit de tabel Contactpersonen haalt. de velden [BedrijdsID] en [Afdeling] haal je vervolgens wèl uit de tabel [tblBedrijfsContactpersonen].
Het effect van de query is, dat je met deze query een nieuw record toevoegt aan de tabel [tblContactpersonen]. Althans: dat is wat er gebeurt als je op de knop Nieuw klikt. Daarna stopt het proces... Je kunt namelijk helemaal geen record toevoegen met deze query, omdat je de gegevens in verschillende tabellen op wilt slaan. Je wilt een ContactpersoonID opslaan in de tabel [tblContactpersonen], en een afdeling in de tabel [tblBedrijfsContactpersonen]. Je kunt echter alleen een afdeling opslaan als je ook een ContactpersoonID invult, en een BedrijfsID. Dat laatste veld staat wel goed, het veld ContactpersoonID dus niet. Het gevolg: je kunt geen records toevoegen.
Kortom: hoe je het ook wendt of keert: het formulier moet als basis de tabel [tblBedrijfsContactpersonen] krijgen. Alle velden die je in wilt vullen in die tabel, moeten dus ook voorkomen in een query die je als basis wilt gebruiken voor dat formulier. Zoals gezegd, dat is nu niet het geval.

Wat betreft de keuzelijsten: deze dienen als basis om gegevens op te zoeken die je op wilt slaan in de tabel die als basis dient voor het formulier. Als je een BedrijfsID wilt invoeren, dan kun je dus een keuzelijst maken die als basis de tabel [tblBedrijven] heeft. Daar gebruik je dan een Recordbron voor die minstens bestaat uit BedrijfsID en Bedrijfsnaam, waarbij je uiteraard sorteert op Bedrijfsnaam. De kolom BedijfsID zou je kunnen verbergen, zodat je de Bedrijfsnamen in beeld ziet, zolang je het BedrijfsID maar opslaat, want dat is het veld dat gevraagd wordt in de tabel [tblBedrijfsContactpersonen]. En zo werken in beginsel alle keuzelijsten: je gebruikt een tabel (mag ook met meerdere tabellen) om een waarde op te zoeken die je vervolgens opslaat in de tabel.

 

[Robbin R]

Goed, dus wellicht is de basis van de database verkeerd gelegd.

In principe ga ik uit van drie tabellen: tblContacts, tblCompanies en tblProductions (zie: Excel bestand)
Iedere tabel is voorzien van een unieke identificatiecode op basis van autonummering.

Wat is nu een goed manier om de drie tabellen met elkaar te verbinden?
Er geldt namelijk...
Contactpersoon: iedere contactpersoon is verbonden aan 1 bedrijf en mogelijk aan meerdere producties

Bedrijf: ieder bedrijf is verbonden aan meerdere personen en meerdere producties

Productie: iedere productie is verbonden aan 1 contactpersoon en aan 1 bedrijf

Hoe breng ik dit nu handig in relatie?
En in principe zou ik ook nog de tabel tblProductions willen opsplitsen in een gedeelte t/m PerPalletComm en dan een andere tabel waarin voor iedere ProductionID een overzicht van alle planning op de rails wordt gehouden.

 

[OctaFish]

Ik gebruik uit principe geen 2007, dus ik kan de laatste db niet openen, maar op basis van je excel bestand, en de vorige db, kan ik je geruststellen; de opzet is op zichzelf niet verkeerd. De enige opmerking die ik heb is dat je in de tabel [tblContactpersoonProducten] een sleutel hebt gedefinieerd op basis van [ProduktID], [BedrijfsID] en [ContactpersoonID]. Dat zou ik zelf niet doen. De eerste vraag daarbij is: hoe uniek s het ProduktID? Als dat een unieke waarde is, dan is dat per definitie al je sleutel. als de produktID's voor meerdere combinaties mogelijk zijn, moet je aan een andere sleutel denken. En daarbij komt dan eerst de vraag op: als het produktid niet uniek is, hoe zit het dan met het produkt? Is dat wel uniek? Want waarom dan niet een unieke code? Als het niet uniek is, en dus net als de ProduktID meerdere keren voorkomt, dan zou ik de produkten (met unieke ProduktID) in een aparte tabel onderbrengen.
Een primaire sleutel moet uit zo min mogelijk velden bestaan: oftwel: de kleinste combinatie die een unieke combinatie vormt. Dus: is het ProduktID uniek, dan is dat je sleutel.

 

[Robbin R]

ProductID, ContactpersoonID en BedrijfsID zijn alle unieke waarden.

Contactpersonen worden aan een bedrijf gelinkt in tblBedrijfsContactpersonen. Deze tabel heeft dus als velden [BedrijfsID] en [ContactpersoonID]. Allebei zijn die van het gegevenstype Numeriek.

Als ik het goed begrijp, moet ik [bedrijfsID] en [ContactpersoonID] in tblBedrijfsContactpersonen dan ook niet aanvinken als primaire sleutel, omdat dat al in respectievelijk de tabellen tblBedrijven en tblContactpersonen is gebeurd.

tblBedrijfsContactpersonen heeft dus alleen als velden [BedrijfsID] en [ContactpersoonID], allebei numeriek en geen primaire sleutel?

 

[OctaFish]

Je begint het licht te zien, maar we zitten nog in de tunnel In de tabel tblContactpersonen in ContactpersoonID inderdaad uniek, omdat elke persoon daar ��n keer voorkomt. In de tabel tblBedrijven geldt hetzelfde voor BedrijfID. Als je wilt voorkomen dat een persoon aan meer dan ��n bedrijf wordt gekoppeld, zou je in de tabel tblBedrijfsContactpersonen het veld ContactpersoonID uniek kunnen maken. Daarmee voorkom je dat een persoon bij meer dan ��n bedrijf werkt. De vraag is, of je dat wel wilt. Een persoon zou bijvoorbeeld eerst bij bedrijf A kunnen werken, en na een jaar naar bedrijf B gaan. Bij het bovenstaande voorbeeld zou dat niet kunnen in de db. Dus doe je dat meestal niet. Omgekeerd geldt hetzelfde voor bedrijven: als je in tblBedrijfsContactpersonen het veld BedrijfsID uniek maakt, mag elk bedrijf maar ��n werknemer hebben. Beetje onzinnige situatie natuurlijk
Dus zie je, wat jij ook gedaan hebt, vaak een combinatiesleutel van ContactpersoonID en BedrijfsID. Hiermee bepaal je dus dat ��n persoon bij ��n bedrijf mag werken: de combinatie vn ContactpersoonID en BedrijfsID is samen uniek. Voor de meeste bedrijven werkt dit prima, al zijn hier ook uitzonderingen op te verzinnen. Ik denk dan bijvoorbeeld aan een dokter die in een groot ziekenhuis is verbonden aan twee verschillende afdelingen, en bij elke afdeling een eigen contract heeft. In eerder genoemde situatie zou dat in de database niet kunnen worden vastgelegd. Het is dus belangrijk dat je van tevoren bedenkt welke combinaties er mogelijk moeten zijn.
Voor het gemak zie je vaak, dat in een gerelateerde tabel een Autonummerveld wordt toegevoegd als sleutel, zodat je in ieder geval een sleutel hebt om de tabel te identificeren.

Als ik het goed begrijp, moet ik [bedrijfsID] en [ContactpersoonID] in tblBedrijfsContactpersonen dan ook niet aanvinken als primaire sleutel, omdat dat al in respectievelijk de tabellen tblBedrijven en tblContactpersonen is gebeurd.

Hopelijk is de fout in je opmerking hiermee voldoende verklaard... Je hebt dus wel degelijk een sleutel nodig; die zou in dit geval uit ContactPersoonID en BedrijfsID kunnen bestaan, als het de bedoeling is dat ��n persoon bij ��n bedrijf mag werken. Je krijgt dan een ��n-op-veel relatie tussen tblBedrijven en tblBedrijfsContactpersonen en tussen tblContactpersoon en tblBedrijfsContactpersonen.

Om nog even terug te komen op ProductID: als dat inderdaad een uniek product is, dan is het voldoende om dat als sleutel te definieren in de tabel tblContactpersoonProducten. Al bereik je daar nu dus mee dat ��n product maar aan ��n persoon en ��n bedrijf kan worden gekoppeld. Ik kan hier vandaan uiteraard niet beoordelen of dat de bedoeling is.