onjuiste query resultaten bij meerdere tabellen

[Accesshelp]

Goedendag,

Ik heb als test voor een uiteindelijk te verwezenlijken oplossing een simpele database gebouwd.
Twee tabellen waarbij het voertuignummer in beide tabellen als join kan worden gemaakt.
Beide tabellen hebben een autonummering.
Als ik een selectiequery maak van één tabel met alle velden, wordt keurig de inhoud van de tabel
als resultaat van de query getoond. Wanneer ik een 2de tabel in het ontwerpraster toevoeg (de ruimte
waarin je de relatie kunt weergeven) zonder daarvan nog velden daadwerkelijk aan de query toe te voegen,
gebeurt er bij het runnen van de query iets vreemds (in mijn ogen dan) Het oorspronkelijke resultaat van
6 records wordt uitgebreid naar wel 48 records waarbij telkens de eerste 6 records worden herhaald.
Of ik nu wel of geen join tussen de tabellen aanbreng lijkt niet uit te maken.
Ik tast even in het duister. Zou iemand zo vriendelijk willen zijn mij op mijn gedachte- en uitvoeringsfout te willen wijzen?
Bij voorbaat dank!

Bekijk bijlage KmstandBijVervangingTestA.zip

 

[JohanRVT]

Dat kan je eenvoudig oplossen door een relatie te leggen tussen de Busnr en BusnrVervanging in je tabellen (je kan dit doen in je query zelf en best ook nog in je "relaties" venster zelf, dan zijn alle toekomstige query's automatisch juist gerelateerd.

 

[OctaFish]

Het antwoord van Johan is een beetje te kort door de bocht, vrees ik. Je hebt 2 tabellen waarin het beoogde koppelveld (Busnr of BusnrVervanging) niet het sleutelveld is. Dat betekent dat er bar lastig te koppelen valt. Eigenlijk mis je nog een tabel: de tabel [tblBus] met daarin per busnr een sleutelveld (Busnr dus) en waar je dan de overige buskenmerken in opslaat. Die tabel koppel je dan aan tblTankgegevens op basis van het veld [Busnr) en de relatie tussen [TblVervanging] en [tblBus] leg je op de velden [BusnrVervanging] resp. [Busnr]. De twee tabellen hebben in mijn ogen niet zo bar veel met elkaar te maken; uiteindelijk is een bus die vervangt nog steeds een bus. En die moet dus ook in de tabel tblBus worden opgenomen.
Eigenlijk gebruik je dus de verkeerde tabellen voor je query, daar komt het op neer.

Het effect dat je nu hebt, heet een Cartesisch product. Dat wordt uitgebreid uitgelegd in de Access cursus (ook waarom het wel eens handig is), dus ik hou het hier kort, ook al omdat je het volgens mij zelf al gevonden hebt. Een CP combineert alle records uit tabel 1 met alle records uit tabel 2. En zet die onder elkaar. Het resultaat is dan een dynamische tabel die alle records van tabel 1 (8 stuks) combineert met alle records van tabel 2 (6 stuks) en dat levert 6 x 8 = 48 records op.

 

[Accesshelp]

Hartelijk dank voor jullie snelle reactie!
Aha, dus toch iets mis met de relaties. Ik had de term Cartesian produkt al gevonden maar begreep niet waarom
de Query daar al last van heeft zonder dat records van de 2de tabel gevraagd worden. Eerlijk gezegd begrijp ik dat
nog steeds niet helemaal maar als Access zo werkt, dan moet ik daar rekening mee houden.
Ik heb de database aangepast en een tabel toegevoegd met daarin het busnr als sleutelveld.
Vervolgens relaties naar eer en geweten aangegeven waarbij in de tabel busnr er sprake is van
één-op-veel relaties naar de overeenkomstige busnr's in de andere tabellen.
Helaas nog steeds teveel Cartesische produkten maar wel minder.
Ik moet het hoofdstuk relaties nog maar eens goed bestuderen.
Als iemand toch nog even naar de aangepaste database zou willen kijken en aangeven
wat er nog aan schort, helpt mij dat enorm.

Hartelijk dank

Bekijk bijlage KmstandBijVervangingTest2.zip

 

[OctaFish]

Zal er vanavond even naar kijken.
Bij een CP gaat het erom dat de tabel er zijn.

 

[JohanRVT]

Michel, da's de eerste maal dat je zegt dat ik ook iets kort kan
Maar ik zie in het 2° voorbeeld dat zijn relatievenster nog steeds leeg is; hij zegt het wel te zullen doen maar 't is er nog niet.
En het koppelveld hoeft belange niet het sleutelveld te zijn.
Verder geraakt ie er ongetwijfeld wel uit met een beetje try en error.

 

[OctaFish]

Als je maar lang genoeg wacht, krijgt iedereen z'n complimentje

Michel, da's de eerste maal dat je zegt dat ik ook iets kort kan

En het koppelveld hoeft belange niet het sleutelveld te zijn.

Dat denk je misschien, maar dat is dus niet zo. OK, technisch gezien kun je in het relatievenster een koppeling maken tussen 2 tabellen met 2 velden, maar als van niet minstens één tabel het sleutelveld wordt gebruikt, is het onmogelijk om Referentiële integriteit af te dwingen. En dat maakt de relatie op slag net zo nuttig als een fiets op de bodem van de zee. Of een achteruitkijkspiegel op de maan. Of zoiets.

 

[OctaFish]

Overigens snap ik de query wel, want in deze vorm hebben de gegevens niet zoveel met elkaar te maken. Je hebt als het ware een veel-op-veel relatie tussen [tblTankgegevens] en [tblVervangingsdata], bij elkaar gehouden door Busnr. Ben benieuwd dus wat TS eigenlijk wil zien van deze gegevens!

 

[Accesshelp]

Dank.
@JohanRVT. Ik heb de relaties er wel in gezet maar ik kom er net achter dat je een apart venster (tabblad) hebt waarmee de relaties kunnen worden ingesteld.
In de database zijn de relaties wel zichtbaar als je de query in ontwerpmodus zet (althans, bij mij dan)
Ik heb met de nieuwe inzichten de database weer even aangepast en de relaties nu anders zichtbaar gemaakt (via lint, tabel, relaties)
Enfin, hoofdstuk relaties nog niet bestudeerd dus huiswerk nog niet gemaakt.
Oplossing voor correcte weergave van query nog niet gevonden.
Ja, resultaten lijken nu nog onzinnig maar dit wordt wel de opzet voor een uitgebreidere toepassing.
Mocht iemand nog naar de database willen kijken dan graag en anders ga ik eerst zelf nog een tijdje goochelen.

Bekijk bijlage KmstandBijVervangingTest3.zip

 

[OctaFish]

In de database zijn de relaties wel zichtbaar als je de query in ontwerpmodus zet (althans, bij mij dan)

Dat zijn geen relaties, maar Query Joins. Is heel wat anders

Oplossing voor correcte weergave van query nog niet gevonden.

De query wordt uiterst correct weergegeven; je vraagt alleen de verkeerde gegevens .

Ik heb uiteraard even naar je relaties gekeken, en daar is maar één woord voor (ik weet het, het klinkt keihard maar je moet dit letterlijk nemen, niet als oordeel): waardeloos. En daar bedoel ik mee: koppelingen zonder enigerlei waarde. Je kunt ze net zo goed weglaten, de db wordt er alleen maar beter van. Wat mankeert er aan? Eigenlijk 2 dingen, waarvan punt 1 vrij dodelijk is voor de kwaliteit van je relaties: je hebt geen Referentiële Integriteit aangeklikt. En zonder dat vinkje heb je geen één-op-veel relatie en kun je net zo goed het veld [datum_kenteken] koppelen aan [kmstand]. Hé, zeg jij dan, maar dat zijn toch totaal verschillende gegevens? Ja, zeg ik dan, en je zou die relatie nooit kunnen maken als je Referentiële Integriteit aanvinkt. Staat Access gelijk op zijn achterste benen. Laat je dat vinkje weg, dan kan het gewoon wel! Ergo: zonder Referentiële Integriteit is elke relatie of koppeling die je legt volslagen nutteloos en, inderdaad, waardeloos!

Tweede puntje dat ik nooit (nou,nooit: bij hoge uitzondering wel eens een keer) doe: de Outer Join optie aanzetten. Is doorgaans volslagen nutteloos en doet meestal meer kwaad dan goed. Dat moet je echt alleen doen als je weet wat je doet. Gebruik in beginsel gewoon de standaard Inner Join (optie 1).

 

[Accesshelp]

Ik heb mij na mijn laatste bericht verdiept in tabelrelaties. Ai, ai, ik heb toch wel serieuze fouten gemaakt.
Ik zou inmiddels de term waardeloos als oordeel ook nog wel accepteren.
Zo blijk ik tabelrelaties verward te hebben met query joins en dacht ik met inner en outer joins
de 1-op-veel relatie in te stellen. Kennis op dit punt was toch wel erg weggezakt.
Inmiddels ook in een Acces boek gelezen dat een tabel toevoegen aan een queryontwerp er toe leidt dat
Access daar ook verbindingen naar legt, ongeacht of je de tabel nu gebruikt of niet.
Had ik al ondervonden maar ook wel fijn als je dat nog ergens terugleest.

Met name Octafish zou ik bijzonder hartelijk willen bedanken voor je heldere uitleg en tijd die je eraan hebt besteed.
Ook JohanRTV bedankt voor je reactie.