Query uit meerdere tabellen niet mogelijk

[fbruin]

Beste mensen,

Ik ben predikant van beroep en wil graag aan mijn kerkenraad maandelijks een lijst overleggen van de bezoeken die ik gebracht heb.

Daarvoor heb ik een tabel "Ledenlijst" en een tabel "Bezoeken" gemaakt.
Van het veld Lidnummer uit "Ledenlijst" heb ik een (een-op-veel) relatie gelegd met het veld Lidnummer in "Bezoeken" en hiervoor referentiele integriteit opgegeven.
In de Query vraag ik uit "Ledenlijst" de naam en adresgegevens van de pastorant op en uit "Bezoeken" de datum en reden van bezoek. Tot zover loopt alles prima.

Nu komt het voor dat mensen door mij bezocht zijn n.a.v. ernstige ziekte en inmiddels overleden zijn. Deze overledenen worden uiteraard uit "Ledenlijst" verwijderd.

Om toch de bezoeken te kunnen rapporteren die ik aan deze mensen gebracht heb, voordat zij kwamen te overlijden, heb ik een tabel "Overledenen" gemaakt, met vrijwel dezelfde structuur als die van ledenlijst. Het veld "Overledenenummer" wordt hierin gemaakt metAutNummering en heeft de primaire sleutel.
In de tabel "Bezoeken" heb ik het veld "Overledenenummer" toegevoegd, dat een relatie heeft met de tabel "Overledenen".

Daarna heb ik een nieuwe Query gemaakt, waarin ik gegevens opvraag uit "Ledenlijst" ,
"Overledenen" en "Bezoeken" . Uit de eerste twee tabellen vraag ik naam+adres, uit de laatste datum+reden bezoek, waarbij de maand waarin het bezoek gebracht is het criterium is.

ECHTER : deze Query levert niet meer dan 1 LEGE RIJ op! Er is NIKS te zien!

Wat doe ik verkeerd ?

Ik heb al gekeken wat er gebeurt als ik de " referentiele integriteit" uit de relaties tussen de tabellen weghaal, maar dat levert ook niks op!

Wie helpt mij ?

 

[Bartuls]

Dat is logisch.
Als je in access referentiele integriteit aanbrengt, dan zal access default veronderstellen dat in dat geval er in beide tabellen één of meerdere voorkomens zijn waar de gekozen velden een gelijke waarde bevatten.
Bij jou is dat niet het geval, er is altijd één van de relaties niet aanwezig, dus krijg je ook niets terug.

Ga naar het overzicht van de tabellen en hun relaties.
Dubbelklik op de relatie.
Druk op knop Jointype...
Kies optie 2 of 3 (wat voor jou van toepassing is).

In plaats van een INNER JOIN heb je er nu een OUTER JOIN van gemaakt.
Dat zal meer records op gaan leveren.

 

[FESTER]

Nu komt het voor dat mensen door mij bezocht zijn n.a.v. ernstige ziekte en inmiddels overleden zijn. Deze overledenen worden uiteraard uit "Ledenlijst" verwijderd.
Om toch de bezoeken te kunnen rapporteren die ik aan deze mensen gebracht heb, voordat zij kwamen te overlijden, heb ik een tabel "Overledenen" gemaakt

Begrijpelijke aanpak maar niet echt verstandig.
Voeg een kolom toe aan je ledenlijst waarin je een afmeldingsdatum vastlegt.
Je kan ook nog een kolom toevoegen met de reden, bijv "verhuisd", "overleden", wat dan ook.

Als je nog mooier wilt doen, gebruik dan een tabel Lidhistorie.
Daarin leg je dan vast:

- ingangsdatum lidmaatschap
- einddatum lidmaatschap
- reden beindiging lidmaatschap

Tabel link je vervolgens naar je ledentabel via een 1 op veel relatie.

Vooral handig als leden zich opnieuw aanmelden, hoef je alleen een nieuwe lidmaatschapsdatum in te vullen.

FESTER

 

[Bartuls]

Begrijpelijke aanpak maar niet echt verstandig.
Voeg een kolom toe aan je ledenlijst waarin je een afmeldingsdatum vastlegt.
Je kan ook nog een kolom toevoegen met de reden, bijv "verhuisd", "overleden", wat dan ook.

Als je nog mooier wilt doen, gebruik dan een tabel Lidhistorie.
Daarin leg je dan vast:

- ingangsdatum lidmaatschap
- einddatum lidmaatschap
- reden beindiging lidmaatschap

Tabel link je vervolgens naar je ledentabel via een 1 op veel relatie.

Vooral handig als leden zich opnieuw aanmelden, hoef je alleen een nieuwe lidmaatschapsdatum in te vullen.

FESTER

Leuke aanbeveling, maar dat betekent in dit geval hoogstwaarschijnlijk dat de halve toepassing aangepast moet worden, alle queries zullen bijvoorbeeld gebaseerd zijn op het huidige datamodel.
De oplossing van het toepassen van OUTER JOINS betekent dat de rest van de toepassing gewoon blijft werken.

 

[FESTER]

Leuke aanbeveling, maar dat betekent in dit geval hoogstwaarschijnlijk dat de halve toepassing aangepast moet worden, alle queries zullen bijvoorbeeld gebaseerd zijn op het huidige datamodel.
De oplossing van het toepassen van OUTER JOINS betekent dat de rest van de toepassing gewoon blijft werken.

Geen leuke aanbeveling beste Bartuls maar gebaseerd op common practice binnen professionele bedrijfsomgevingen

FESTER

 

[Bartuls]

Fester,

De reden dat ik de OUTER JOIN aanbeveel is ook gebaseerd op professionele ervaring (MCSD) met access vanaf versie 2.0.
In bestaande toepassingen (onderhoud dus) doe je geen aanpassingen die een herbouw van de gehele toepassing noodzakelijk maken, tenzij je oneindig veel tijd en of oneindig veel budget tot je beschikking hebt.
In dit geval is de OUTER JOIN de beste oplossing om snel het gewenste resultaat te krijgen.
Aangezien je een dergelijke OUTER JOIN ook binnen queries kan aanbrengen (op dezelfde manier als ik voor het wijzigen van het model beschreven heb) hoeft dat helemaal geen bezwaar te zijn, aangezien je dan je datamodel in tact kan laten.
Dus nogmaals, jou aanbeveling is veel te kort door de bocht voor een bestaande toepassing, dat pas je alleen toe als je met een nieuwe toepassing bezig bent.

Ook wil ik voorstellen deze discussie te stoppen en de het initiatief voor het kiezen van de gewenste oplossing aan de starter van het topic over te laten, hij kan het beste inschatten wat voor hem de beste oplossing is.
Afhankelijk van de door hem gekozen oplossing kunnen we hem dan van verder advies voorzien.

 

[FESTER]

Dus nogmaals, jou aanbeveling is veel te kort door de bocht voor een bestaande toepassing, dat pas je alleen toe als je met een nieuwe toepassing bezig bent.

Da's eerder jouw persoonlijke mening dan een feit.
De redenen die je aanvoert zijn begrijpelijk ergo niet per definitie valide en zeker niet zo zwart wit als je dat meent te moeten stellen.
En zeker niet in dit geval, de vragensteller is net bezig.
Reden des te meer om 'm op het rechte spoor te zetten en niet direkt met stoplappen aan de slag te laten gaan

Iedereen heeft recht op zijn of haar eigen waarheden zullen we maar zeggen
Discussie gesloten, terug naar het draadje.

FESTER

 

[fbruin]

Beste mensen,

Ik ben nog niet zo ervaren op deze site....maar om te beginnen wil ik jullie hartelijk bedanken voor de geboden hulp.

Ik heb de eerst aangereikte oplossing toegepast (en kwam erachter dat ik niet alleen inm het relatieveld, maar ook in de Query zelf die OUTER JOIN moest maken, maar dat geeft niet) en het werkt!!!! Dank aan Bartuls!

De oplossing van Fester kan ik ook nog wel volgen (en mijn database is nog niet zo vergevorderd, dat het enorme ombouwproblemen geeft, zoals Bartuls veronderstelt),
alleen wat mij aan de oplossing van Fester niet duidelijk is, is of mijn Ledenlijst wel schoon blijft als ik daar ook de namen van overleden mensen in laat staan.

Stel dat ik naam en adres van iemand wil opzoeken in mijn ledenlijst .... en het is naam
die wel vaker voorkomt.....dan is het toch heel vervelend om bij de zoekresulateten de namen+adressen van overleden mensen te krijgen ???

Wat is hierop het antwoord ? Ik ben benieuwd

fbruin

 

[FESTER]

Wat je kan doen is een ja/ nee kolom toevoegen aan je ledentabel.
Die gebruik je om aan te geven of een iemand nog lid is of niet.

Zoeken doe je vervolgens op mensen die nog lid zijn.
Daarvoor maak je dan een query.
In de query neem je als criterium de waarde -1 voor de ja/nee kolom op.

FESTER

 

[fbruin]

Dank voor alle hulp!

Frank B