resultaat van 3 master/detail comboboxen naar 1 tabel

[skyrat]

Sinds kort ben ik noodgedwongen iets voor iemand anders aan het doen met Access. Tot nu toe is mijn voornaamste ervaring hiermee dat het de meest onduidelijke en niet-transparante database omgeving is die ik ooit heb meegemaakt !
Om met het probleem simpel te kunnen experimenteren heb ik een eenvoudig model opgesteld :

Tabel Wereld : WereldID (autoNummering), LandNaam, ProvNaam,StadNaam
Tabel Land : LandID (autoNummering),LandNaam
Tabel Provincie : ProvID (autoNummering),LandID,ProvNaam
Tabel Stad : StadID (autoNummering),ProvID,StadNaam

Het is me uiteindelijk gelukt om een formulier te maken met 3 comboboxen (voor Land,Provincie en Stad). Als ik nu een Land kies krijg ik in de combobox van Provincie alleen de provincies van dat land enz.
Het probleem is nu dat in de tabel Wereld NIET de LandNAAM enz. terechtkomen, maar alleen de landID enz.
De koppeling van de comboboxen gaat dus goed, maar bij het wegschrijven naar Wereld gaat er iets mis !

En zojuist merk ik dat het hier bijvoegen van het bestand KeuzeTest.mdb ook niet lukt : melding Geen geldig bestand !!

 

[skyrat]

zipper

Kijken of een zipper wel lukt !Bekijk bijlage KeuzeTest.zip

Dat lijkt zowaar te lukken ! :thumb:

 

[OctaFish]

Tot nu toe is mijn voornaamste ervaring hiermee dat het de meest onduidelijke en niet-transparante database omgeving is die ik ooit heb meegemaakt!

Wonderlijke ervaring; ik zou hem 180 graden willen omdraaien. Ik ken geen enkele omgeving die zo krachtig en compleet is. Wellicht ontbreekt je de kennis om er goed mee te kunnen werken .
Ik snap niet wat je wilt bereiken met die overbodige tabel Wereld. Als ik de lijn vanaf stad naar land doortrek, moet de tabel Wereld slechts LandID's bevatten, en verder niks. OK, de naam van de verschillende werelden. Aarde 1, Aarde 2 etc. Maar verder nut? Ik zie 'm niet. De velden die je daarin wilt opslaan, kun je allemaal met een query bevragen. Dus geen tabel nodig.

 

[skyrat]

Wonderlijke ervaring; ik zou hem 180 graden willen omdraaien. Ik ken geen enkele omgeving die zo krachtig en compleet is. Wellicht ontbreekt je de kennis om er goed mee te kunnen werken .

Dat zal het wel zijn dan Ik heb dan ook met mijn 81 jaar alleen ervaring met grote echte databases als Interbase,(in de oude tijd) DBase, Firebird,Oracle enz.
Maar goed, het is dus niet duidelijk wat hier de bedoeling is. "Wereld" staat hier in werkelijkheid voor een grote tabel met veel velden. Via het formulier wil ik steeds in 1 record 3 bepaalde, van elkaar afhankelijke, velden kunnen invoeren via 3 comboboxen. Waarom krijg ik dan alleen de ID's en niet de LandNaam,ProvincieNaam en StadNaam ? DAT is het probleem !!

 

[OctaFish]

Als je al zolang met databases werkt (dBase staat overigens tot Access als een driewieler tot een mountainbike) zou je van normalisatie behoorlijk wat kaas gegeten moeten hebb3n, en dan weet je ook dat dat ‘not done’ is in een database; je slaat alleen de verwijzingen op. Dus, zoals je nu ook hebt, de ID’s. En nogmaals: zelfs dát is al teveel, want vanuit de relaties tussen de tabellen hoef je alleen het StadID op te slaan. Want StadID —> ProvincieID —> LandID.

Oftewel: als je de stad weet, weet je ook in welke provincie die ligt, en van de provincie weet je in welk land die ligt. Door alle overige velden ook nog eens apart toe te voegen, introduceer je data-inconsistentie. In jouw opzet kun je de stad Utrecht kiezen, die in de provincie Vlaanderen ligt in Duitsland. Niet direct in je formulieren (dat kun je nog afvangen met afhankelijkheden) maar wel in rechtstreeks in de tabel.
Ik heb dan wel geen 81 jaar ervaring met databases (ik kom tot de helft) maar dit soort ‘fouten’ heb ik nog nooit in een database, hoe groot ook (MS-SQLServer systemen) gemaakt.

 

[skyrat]

Foute database

Natuurlijk heb je gelijk dat de database volkomen verkeerd is opgezet en ik zou het uiteraard ook heel anders hebben gedaan. Het probleem is dat de hele zaak ruim 20 jaar geleden door amateurs in elkaar is gezet, daarna door anderen is overgenomen en stukje bij beetje is uitgebreid, opnieuw door mensen die weinig of niets van databases wisten. De manier waarop ze nu werken gaat dus inderdaad via een aantal comboboxen en hun enige wens was om de lengte van de lijsten van die comboboxen te beperken.( Probeer maar eens om mensen die gewend zijn om op een bepaalde manier te werken te laten omschakelen! ) In hun opzet zijn die nl niet gekoppeld,zodat ze ,om met het testje te spreken, in de lijst van de provincies ALLE provincies van ALLE landen staan. Om te trachten ze voorlopig toch te helpen heb ik eerst eens het testje gemaakt en gekeken of zelfs Access in staat zou zijn om die koppelingen te maken, zonder dat ik alles opnieuw zou moeten bouwen. In hun "echte" Wereld staan nl wel degelijk de LandNaam, ProvincieNaam en Stadnaam (en dus niet de ID's). Afgezien van de slechte opzet vind ik het toch vreemd dat nu door het koppelen van de comboboxen de ID's i.p.v. de namen worden opgeslagen. Ik zie dus kennelijk toch nog iets over het hoofd in Access ! Gaarne hierop nog een reactie.
Inmiddels heb ik alvast in Delphi met behulp van ADO componenten een schil geschreven die , om in de Test termen te blijven, alleen StadID opslaat en een ADOquery een Wereld record laat ophalen met de diverse namen.Voor mij persoonlijk werken Delphi en ADO vele malen makkelijker omdat ik daar veel meer in thuis ben. In Access zoek ik me (nog) elke keer rot als ik iets wil doen !

Inmiddels is het me gelukt om zelfs in Access het voorbeeldje zo te maken dat in Wereld ALLEEN de velden WereldID en StadID staan. Met een selectquery qWereld kan ik nu de LandNaam,ProvincieNaam en StadsNaam krijgen. Het was wel nog even stoeien met de lastige manier waarop Access daarin met haakjes omgaat bij meerdere joins, maar uiteindelijk is het gelukt en kan ik dus het geleerde op het echte project loslaten.
Nog hartelijk dank voor je commentaren en het meedenken. Hiermee is dus dit probleem opgelost ! :thumb::thumb::d