Relatie probleem

Iets wat in een oude Acces DB wel werkte, krijg ik nu niet voor elkaar. Het gaat om een ziekteverzuimregistratiesysteem. De basis is een tbl_Persoonsgegevens met als primaire sleutel: Pers_ID
Dan is er een tbl_Ziektverzuimgegevens. Deze heeft een koppeling met de tbl_Persoongegevens, d.m.v een één op veel relatie met de Pers_ID. (een persoon kan immers meerdere keren ziek zijn).
Elk ziektegeval is uniek gevalsnummer en dat is dan ook de primaire sleutel. Dat werkt goed.

Nu heb ik ook een tbl_Logboek gemaakt, waarin ik de contactmomenten/acties in het kader van één ziektegeval kan noteren. Deze is gekoppeld aan de tbl_Ziekteverzuimgegevens. Ook d.m.v. een één op veel relatie. Want per ziektegeval kun je meerdere contactmomenten/acties hebben.

Als ik op het frm_Ziekteverzuimgegevens open en bijvoorbeeld ziektegevalsnummer 84 bekijk en in dat geval op de knop druk (= frm_Logboek openen) om het logboek te openen, dan worden niet de logboekitems van ziektegeval 84 er bij gehaald. Ik kan wel bij het veld ziektegevalsgegevens nummer 84 eruit kiezen en dan krijg ik wel de juiste logboekitems.

Ik kom er nog niet uit waar ik een fout maak. Wie kan mij inspireren met mogelijke fouten?
Alvast bedankt!

Het probleem zit 'm in ieder geval niet in je relaties, die zijn goed. Een tweede formulier openen op basis van gegevens uit een ander formulier, werkt alleen goed als de betreffende sleutel correct wordt meegegeven als filter op je tweede formulier. En daar gaat het dus fout. Waarom, is zonder de code(s) te zien verder niet te zeggen.

Bedankt voor je bericht.
Excuus voor mijn later reactie. Dat had te maken met familieomstandigheden.

Goed om te vernemen dat de Relaties goed zijn. Bij nadere bestudering blijkt dat ik niet de tbl_Ziekteverzuimgegevens gebruik, maar een Qry_Ziekteverzuimgegevens. Deze qry is gebaseerd op de tbl_Ziekteverzuimgegevens. Het enige wat die Qry doet is het aantal ziektedagen berekenen tussen eerste en laatste ziektedag en presenteert dat op het formulier (mij is geleerd dat berekeningen in een qry beter is dan in een formulier of rapport. Vandaar deze qry).

Met een qry kan ik geen relaties leggen. Dus ik denk dat ik de Qry verwijder en zuiver alleen met de tbl ga werken. Is deze gedachtegang correct?

Alvast bedankt voor je reactie.

Dag WiSPi,

als je de correcte relaties legt tussen de tabellen, dan worden deze automatisch overganomen in elke query die deze tabellen gebruikt, tenzij je deze zelf handmatig in die specifieke query aanpast.
In queries kan je bovendien relaties leggen tussen tabellen en queries. Ik zie dus geen enkele reden dat je niet met je query zou kunnen verder werken.
Het enige waar je mee moet opletten is dat sommige (bv. totaal queries) niet langer aanpasbaar zijn, zodat ze niet geschikt zijn als basis voor een formulier waarmee je de gegevens moet aanpassen.

Vriendelijke groeten
Noëlla

Dank je wel Noella,

De qry vormt de basis van het formulier Ziekteverzuimgegevens en bij een nieuw ziektegeval vul ik in feite de qry in. Die gegevens zie ik ook terug in de tbl Ziekteverzuimgegevens. Verder is alles 1 op 1 met als enig verschil dat de qry het aantal ziektedagen berekent.

Dan moet ik even uitvogelen hoe ik een relatie tussen een tbl en een qry leg. Nooit geweten dat dit kon.
Dat ga ik eerst doen.

Bedankt,
Wim

Om een relatie tussen een query en een tabel te leggen moet je een nieuwe query aanmaken en binnen deze query kan dit.
In het algemeen relatiemodel is dit niet nodig, omdat daar de algemene gegevens structuur (het datamodel) wordt uitgetekend, die overal blijft gelden.

NoellaG zei:

als je de correcte relaties legt tussen de tabellen, dan worden deze automatisch overganomen in elke query die deze tabellen gebruikt, tenzij je deze zelf handmatig in die specifieke query aanpast.

Klik om te vergroten...

Dit klopt niet helemaal; relaties leg je eigenlijk per definitie alleen in het Relaties venster. Dat is ook de enige plek waar je Referentiële Integriteit kunt afdwingen, een absoluut noodzakelijk eis als je relaties gaat leggen. In queries leg je eigenlijk nooit relaties vast, maar maak je een koppeling tussen twee gegevensbronnen. En dat is iets anders als een relatie.

Daarbij is het inderdaad zo dat als je de gekoppelde tabellen (gekoppeld in het Relaties venster) in een query zet, dat Access die koppelingen automatisch meeneemt naar de query. En dat is wel zo handig. Wat Noëlla hier zegt (tenzij je deze zelf handmatig in die specifieke query aanpast) is dus niet helemaal juist, want van 'tenzij' is helemaal geen sprake: de koppelingen krijg je altijd. Tenzij (Maar dit is een ander geval) je één of meer tabellen uit een keten niet in de query hebt opgenomen. Als je in een query de tabel tPersonen plaatst, en de tabel tFactuurregels, dan zul je de koppelingen niet zien, omdat je de tabel tFactuur niet hebt meegenomen. Die zit tussen de twee tabellen in, en is dus noodzakelijk voor de koppelingen in de query.
Een query op basis van meerdere tabellen zonder koppeling laat in beginsel een Cartesisch Product zien, wat soms ook wel eens handig kan zijn. Het effect van de koppeling kun je daarnaast ook bereiken door de query te filteren op het koppelveld.

Het is daarnaast zo dat je in het query ontwerpscherm de standaard koppeling kunt aanpassen, door op de koppeling te dubbelklikken. Je kunt dus van een Inner Join een Left Outer Join maken, of een Right Outer Join. Dat doe je dan als je bijvoorbeeld niet-gerelateerde waarden wilt zien. Er zijn mensen die dat ook in het Relaties venster doen, maar dat raadt ik ten zeerste af, want je schept alleen maar de mogelijkheid om rotzooi in je tabellen te zetten. Moet je niet willen .

Als laatste opmerking nog deze: als je geen relaties hebt gelegd, en twee tabellen in een query zet die eigenlijk wel gekoppeld zouden moeten worden, en die koppelvelden hebben een identieke naam, dan zal Access die koppeling zelf al maken. Op die manier krijg je toch valide gegevens uit je query, en je hoeft dan de relatie niet zelf te maken. Wat overigens niet zo heel moeilijk is.

Ik zou dus, als ik wispi was, alle relaties in het Relaties venster maken, die je nodig hebt om correcte data op te slaan. En dan hoef je dat in queries eigenlijk nooit te doen, hooguit dus een enkele keer een aanpassing als je een ander resultaat wilt zien.

Dag Octafish,

in een query kan je wel degelijk de relaties die je in het relatievenster gelegd hebt breken of aanpassen of nieuwe relaties leggen. De nieuwe situatie geldt dan alleen binnen deze query definitie en niet voor de rest van de database. Je kan daar bv. ook relaties leggen tussen tabellen en queries, of queries met andere queries, wat SQL tot een zeer flexibele taal maakt. Probeer het maar. Sommige joins zijn misschien niet de slimste, maar dat is een andere zaak. En de constraints die je in het datamodel gelegd hebt (zoals bv. de referentiële integriteit) blijven natuurlijk bestaan. Maar bv. voor export of import redenen heb ik in de praktijk al de bestaande relaties in een query verwijderd en andere gelegd.
Waar ik wel mee oppas is overal referentiële integriteit af te dwingen, zeker als een een tabel aan meerdere andere wordt gerelateerd (typisch hier is de users tabel die naar alle tabellen 2 keer gelinkt wordt naar de CreatedBy en de LastUpdatedBy velden). Dit kan ongewenste blokkades met zich meebrengen en is zeker nefast voor de snelheid en efficiëntie van je database. In kleine systemen valt dit wel mee, maar als men later gaat upgraden kan dit problemen geven.

NoellaG zei:

in een query kan je wel degelijk de relaties die je in het relatievenster gelegd hebt breken of aanpassen of nieuwe relaties leggen.

Klik om te vergroten...

Klopt; ik zei ook niet dat het niet kan. Maar ik zei ook dat je dat alleen doet als je de koppeling wilt veranderen.

NoellaG zei:

Je kan daar bv. ook relaties leggen tussen tabellen en queries, of queries met andere queries, wat SQL tot een zeer flexibele taal maakt. Probeer het maar.

Klik om te vergroten...

Nou niet net gaan doen of ik nog nooit een query heb aangepast, of nog nooit koppelingen heb gelegd tussen tabellen en queries. Je mag mij best wat hoger inschatten . Bovendien: je legt geen Relaties (relationships in database termen) maar koppelingen (Joins geheten). En dat zijn echt twee verschillende dingen. En die kun je in queries dus ook bereiken door geen JOIN te gebruiken, maar een WHERE

NoellaG zei:

En de constraints die je in het datamodel gelegd hebt (zoals bv. de referentiële integriteit) blijven natuurlijk bestaan.

Klik om te vergroten...

Klopt, Relaties hebben namelijk niks met queries te maken.

NoellaG zei:

Waar ik wel mee oppas is overal referentiële integriteit af te dwingen, zeker als een een tabel aan meerdere andere wordt gerelateerd

Klik om te vergroten...

Dan doe je volgens mij toch iets niet helemaal goed, want Referentiële Integriteit is noodzakelijk voor alle relaties die je tussen tabellen legt. Laat je RI weg, dan is je relatie volslagen nutteloos. Dan kun je net zo goed een tabel tPersonen koppelen aan de tabel tBestellingen op basis van de velden Tussenvoegsel en Kledingmaat; de relatie doet dan namelijk niks. Relaties zonder RI zijn dus totaal waardeloos.

eh..... vinden jullie het goed dat ik mij niet aan deze discussie waag en meng?

Ik ga denk toch voor simpel. Dat betekent: ik verwijder de qry en ga de tbl gebruiken. Volgens mij moet ik dan mijn probleem hebben opgelost. De berekening doe ik dan wel in het rapport (= aantal dagen ziek) en formulier.

Ik koppel het resultaat nog terug.

Groet, Wim

Is niet echt een discussie hoor, net zoals je niet kunt discussiëren over de vraag of water nat is, eigenlijk . Je hebt gelijk dat je het simpel houdt, maar dat houdt dan m.i. in dat je de relaties dus correct legt in het Relatievenster, en verder gewoon je berekeningen in je queries maakt, die je dan op je formulier of rapport laat zien. Dat is de makkelijkste oplossing. .

Hoi, ik vind het anders een interessante discussie en apprecieer alle andere meningen, misschien kunnen we hier een apart topic voor maken. Wat het nut is voor gewone relaties in Access: performantie van je systeem. De query engine gebruikt deze om een meer performant query plan op te stellen.
In onze productie systemen (die natuurlijk niet op Access tabellen draaien) bestaat in elke tabel een PK constraint, maar de relaties worden in veel gevallen via joins gelegd. Probeer in Microsoft databases het gebruik van WHERE te vermijden als join, dat heeft serieuze repercuties op de performance. In Oracle SQL echter is dit de normale werkwijze. Alles is niet zo zwart-wit, een extra constraint kan soms net het systeem vertragen in plaats versnellen. Access kan misschien hier en daar verschillen van de echte database systemen, maar de basis principes zijn hetzelfde.

Een discussie moet gaan over discutabele zaken, niet over feiten. Relaties in Access doen niets voor je performance, die wordt er niet sneller of trager van, maar zorgt voor gegevensintegriteit: voorkomen dat je verkeerde gegevens invoert. That’s it. Dat er enig verschil is in JOIN en WHERE qua performance waag ik te betwijfelen; ik heb dat in ieder geval in mijn systemen niet zo gemerkt. Verschil tussen WHERE en HAVING daarentegen wel.
En of een Access frontend tegen een Oracle backend te hangen een goed idee is?

NoellaG zei:

Hoi, ik vind het anders een interessante discussie en apprecieer alle andere meningen, misschien kunnen we hier een apart topic voor maken. Wat het nut is voor gewone relaties in Access: performantie van je systeem.

Klik om te vergroten...

Interessant onderwerp? zeker. En als je wilt discuseren over Access nog beter (als ik Octafish mag geloven ) Maar kijk eerst even of dat al niet beschreven is in de Access handleidingen sectie van Octafish dat voorkomt een hoop heen en weer gepraat in een topic van een vragensteller. 28 handleidingen voor Access kant en klaar en van een hoog niveau, waar? Daar > https://handleiding.helpmij.nl/handleiding/?mid=338

Ik kom er toch niet uit. De qry_Ziekteverzuimgevallen heb ik vervangen door een tbl_Ziekteverzuimgevallen, maar het resultaat blijft hetzelfde. Ik zal eerst beschrijven wat ik heb:

Tbl_persoonsgegevens:
In deze tbl staan de NAW gegevens van een persoon. De Persoon_ID is de primaire sleutel (PS)

Tbl_Ziekteverzuimgevallen:
In deze tbl staan ziekteverzuimperioden. Een persoon kan meerdere ziekteverzuimperioden hebben. Ziektegeval_ID is de PS.

Tbl_logboek:
In deze tbl staan contactmomenten met de zieke persoon. Bij een ziektegeval worden daar notitie van gemaakt. Meerdere notities hebben betrekking op 1 ziektegeval. Logboek_ID is de PS


De relaties:
Tussen Tbl_Persoonsgegevens en Tbl_Ziekteverzuimgevallen heb ik een '1 op veel' relatie gemaakt. Eén persoon kan meerdere ziektgevalperioden hebben. De relatie is gelegd tussen Persoon_ID (één) en Ziektegeval_ID(veel). Referentiële integriteit afdwingen en jointype 2. Deze relatie werkt goed.

Tussen Tbl Ziekteverzuimgegevens en Tbl_Logboek heb ik een '1 op veel' relatie gemaakt. Een ziektegeval kan meerdere logboeknotities hebben. Wat ik ook doe met de eigenschappen: er gebeurt niets. Enkele testnotities staan bij alle ziekteverzuimgevallen van andere personen en/of andere ziektegevallen van 1 persoon.


Als ik Referentiële integriteit wil afdwingen, dan krijg ik de volgende foutmelding:

"Microsoft Access kan geen relatie maken waarvoor referentiële integriteit moet worden afgedwongen.
De gegevens in de tbl-Logboek zijn strijdig met de regels voor referentiële integriteit
De gerelateerde tabel bavet bijvoorbeeld record die verwijzen naar een werknemer terwijl de primaire tabel geen overeenkomende record voor de werknemer bevat.
Bewerk de gegevens zodat er primaire record bestaan voor alle gerelateerde records".

Verder geeft men aan dat ik ook kan kiezen om geen referentiële integriteit toe te passen. Maar als ik dat doe, vindt er ook geen koppeling plaats tussen de tbl_Ziektegevallen en de Tbl_Logboek.

Aanvullende informatie
Er wordt gesproken over 'werknemer'. In databasetermen gesproken ontstaat er pas een 'werknemer', als er een koppeling plaats vindt tussen een 'persoon' (tbl_Persoonsgegevens) en een 'bedrijf'(tbl_Bedrijfsgegevens). Dat gebeurt in de tbl_Dienstverbanden. Moet ik dan de tbl_Dienstverbanden ook betrekken bij het leggen van relaties?

Ik hoop dat iemand mij op het goede spoor kan zetten, wat er bij mij fout gaat. Mijn Access kennis is beperkt. Als het te moeilijk wordt, dan voeg ik geen tbl_logboek toe.
Alvast bedankt voor het meedenken.

Wim

Dag Wispi, het verschil tussen een relatie met referentiële integriteit en een gewone relatie is dat referentiële integriteit controleert of er voor elk gegeven dat in de gelinkte kolom aan de veel kant wel degelijk een gegeven bestaat aan de één kant van de relatie, en aan de één kant van de relatie kan je ook geen gegevens wissen zolang er een overeenkomend record bestaat aan de veelkant van de relatie. Dit is dus belangrijk voor je hoofdstructuur om te voorkomen dat er wezen ontstaan aan de veelkant. Een wees zou zijn dat er een logboekentry is voor ziektegeval 20 en ziektegeval 20 bestaat niet. Een relatie zonder referentiële integriteit heeft deze controles niet, maar is wel degelijk een relatie. Omdat die controles natuurlijk de database vertragen ga je die alleen gebruiken waar die bescherming nodig is. Bijvoorbeeld als je metadata in je database hebt zoals CreatedBy, LastUpdatedBy in elke tabel van de database ga je daar echt geen referentiële integriteit over afdwingen.
Als ik het goed heb is de relatie tussen bedrijven en werknemers via de tabel dienstverbanden. Dus ik neem aan dat dit in se een veel op veel relatie is: één bedrijf kan meerdere werknemers hebben, maar één werknemer kan ook bij verschillend werknemers werken, waarschijnlijk begrensd in een bepaalde periode.
Als je in een query van werknemer naar de logboekentries wil gaan, dan moet je in je query de joins naar de tabel dienstverbanden meenemen, maar daarom moet je die niet noodzakelijk in het eindresultaat tonen. Zoiets als (fictieve veldnamen):

SELECT B.BedrijfsnaamNaam, P.Voornaam, P.Familienaam, Z.Ziektegevalomschrijving, L.Logboeknotitie, L.datum
FROM tbl_Bedrijfsgegevens B inner join tbl_Dienstverbanden D on B.ID = D.BedrijfsID
inner join tbl_Persoonsgegevens P on D.PersoonsID = P.ID
inner join Tbl_Ziekteverzuimgevallen Z on P.ID = Z.PersoonsID
inner join Tbl_Logboek L on Z.ID = L.ZiektegevalID
WHERE ………..
ORDER BY …….

Als je een relatie (ook een ongecontroleerde) hebt gelegd tussen de verschillende tabellen en in je Query-By-Example rooster de tabel dienstverbanden op het scherm zet, dan zal die join ook automatisch in je query opgenomen worden. Anders kan je in de SQL weergave altijd eens de syntax controleren.

Vriendelijke groeten
Noëlla

WiSpi zei:

Tbl_persoonsgegevens:
In deze tbl staan de NAW gegevens van een persoon. De Persoon_ID is de primaire sleutel (PS)

Tbl_Ziekteverzuimgevallen:
In deze tbl staan ziekteverzuimperioden. Een persoon kan meerdere ziekteverzuimperioden hebben. Ziektegeval_ID is de PS.

De relaties:
Tussen Tbl_Persoonsgegevens en Tbl_Ziekteverzuimgevallen heb ik een '1 op veel' relatie gemaakt. Eén persoon kan meerdere ziektgevalperioden hebben. De relatie is gelegd tussen Persoon_ID (één) en Ziektegeval_ID(veel). Referentiële integriteit afdwingen en jointype 2. Deze relatie werkt goed.

Klik om te vergroten...

Dit snap ik niet; je geeft aan dat Ziektegeval_ID en sleutelveld is in de tabel Ziekteverzuim, en Persoon_ID is de sleutel in Persoonsgegevens. Dit is correct waar het de sleutels betreft, maar fout waar het de Relatie betreft. In de tabel Ziekteverzuim hoor je op zijn minst een veld Persoon_ID te hebben (uiteraard geen sleutel, want elke persoon kan meerdere verzuimen hebben) en dat zijn dus de twee tabellen die je moet koppelen. En niet met optie 2, wat in mijn ogen onzin is (net als een deel van het verhaal van Noella, maar daar gaan we het hier niet over hebben) maar dus gewoon met optie 1. Geen verzuimen toestaan van personen die niet bestaan! Zeg nou zelf: het is toch onzin om een verzuim van iemand te registreren van iemand die niet bij jou werkt?

Idem dus ook voor je tabel Logboek: in die tabel moet je dus ook een veld Ziektegeval_ID hebben, dat geen sleutelveld is, en dus meerdere keren voor mag komen. Per ziekteverzuim mag je meerdere logboekregistraties maken. Relatie is hetzelfde: Referentiële Integriteit aanvinken, en optie 1 gebruiken (je gaat geen gesprekken opslaan voor ziekteverzuimen die niet bestaan. Tenzij natuurlijk voor niet-bestaande personen, dan maakt het niks uit ).

De tabel Bedrijven (waar je het nog niet over gehad hebt, overigens) doet in jouw ziekteverzuim niet ter zake; dit maakt de zaak hooguit gecompliceerd als je werknemers hebt die tegelijkertijd bij twee bedrijven tegelijk werken. Wie gaan dan wat betalen van het ziekteverzuim? Maar nogmaals: voor de registratie ervan mag het niks uitmaken.

Wordt het niet eens tijd voor een voorbeeldje met dummy data? Jouw vraag is in mijn ogen een hele simpele, die al lang en breed hard moeten werken...

Bedankt!

Wat verstaan jullie onder dummy. Er staan veel vertrouwelijke gegevens in de db.
Ik heb even foto's gemaakt zoals het nu staat en niet werkt.

Foto1: zo zien de 3 tabellen eruit. Links staat nog een tbl_Hersteldmelden. Dat is een keuzelijst. Meer niet.
Foto2: Dat is de relatie met het scherm 'Relaties bewerken' tussen de tbl_Persoonsgegevens en de tbl_ziekteverzuimgevallen. Daar kan ik referentiële integriteit afdwingen en het Jointype is 1. Deze werkt goed. In het formulier zie ik een persoon met al zijn ziekmeldingen staan.
Foto3: Dat is de relatie met het scherm 'Relaties bewerken' tussen de tbl_Ziekteverzuimgevallen en tbl_Logboek_ZV. Daar kan ik geen referentiële integriteit afdwingen, want dan krijg ik de melding, zoals ik eerder heb gepost (cursieve tekst). Zoals hij nu is kan het wel opslaan, maar laat hij bij alle ziektegevallen van 1 persoon of andere personen alle logboekitems zien.

Als jullie een dummy wenselijker vinden, dan graag even aangeven welke gegevens jullie nodig hebben. Ik kan dat niet op korte termijn doen, maar dan kom ik er later op terug.

Alvast bedankt!

Het probleem zit 'm niet in de tabel Personen, die goed is gekoppeld (gelukkig met de juiste velden . Maar de relatie tussen tblLogboek en tblZiekteverzuim deugt dus niet. De huidige 'relatie' is net zo nuttig als de relatie tussen [Opmerkingen] en [6BA_Gedaan]. Zinloos. Er zijn meerdere redenen waarom je de relatie niet kan leggen. De belangrijkste:
1. Je hebt in Logboek VerzuimID's opgenomen die niet (meer) in tblZiektegevallen staan.
2. De gegevenstypes komen niet overeen. Als Ziektegeval_ID numeriek is (lange integer, Autonummer) en Ziektverzuim_ID is een tekstveld, of een numeriek veld van een ander type, dan kan je niet koppelen.

Het tweede geval is het simpelst op te lossen door het gegevenstype van het veld aan te passen. Eventueel zou je dan eerst een export moeten maken van de tabel, om de inhoud te borgen. Als je een tekstveld gebruikt voor Ziektverzuim_ID, en er staan ook daadwerkelijk teksten in, dan raak je die kwijt als je het veld omzet naar een numeriek veld. Wat je dus moet doen om de koppeling te kunnen maken.
Het sleutelveld aanpassen zou ik in ieder geval niet doen, omdat je daar uiteraard niks kwijt mag raken.

Het eerste probleem is op te lossen door een query Niet-gerelateerde records te draaien op de twee tabellen, en te kijken welke records dan in tblLogboek staan die niet in tblZiektegevallen staan. Vervolgens moet je beslissen of je die records verwijdert, of de nummers nog kan toevoegen aan tblZiektegevallen. Meestal zal dat niet gelijk lukken, als je voor het veld een Autonummer gebruikt, want daar kan je geen tussenliggende nummers toevoegen, hooguit oplopende nummers vanaf het hoogste nummer.

Overigens zou ik nog eens kijken naar je veldnamen; hou ze kort, zonder spaties en zonder leestekens. En slashes zijn ook al niet best.

Bedankt.

Mogelijkheid 1: De tbl_Logboek neemt geen ziekteverzuim ID op. Die staat altijd op 0 (nul). Zie foto4.
Mogelijkheid 2: De gegevenstype voor ZiekteverzuimID in de tbl_Logboek_ZV is nummeriek (lange integer, Autonummer). Dat is dus wel goed.

Wat ik wel heb weggehaald is de standaardwaarde 0. Nu heb ik wel op kunnen slaan met referentiële integriteit. Die foutmelding komt niet naar voren. Dat lijkt winst te zijn, maar lost niets op.
Als ik de tbl_Logboek vul, dan blijft het veld met Ziektgevals_ID altijd leeg.
Er vindt dus geen koppeling plaats van een Logboekrecord aan een ZiektegevalsID. Welk jointype ik ook gebruik.

Als ik het gebruik, dan is er een basisformulier o.a. op basis van de persoonsgegevens. Op dit basisformulier staat een subformulier op basis van de tbl_Ziekteverzuimgevallen. Dat werkt.
Zou het kunnen zijn dat het pas werkt als ik op het subformulier Ziekteverzuimgevallen een subform maak voor de tbl_Logboek_ZV? (nu heb ik op het frm ziektegevallen een Knop zitten die het frm Logboek ZV opent. Het is maar een idee.