Krijg 3 tabellen niet gekoppeld

[PKlabbers]

Goedendag,
Ik ben Patrick en probeer al een hele tijd om op de een of andere manier 3 tabellen te koppelen aan 1 tabel maar ik weet niet hoe ik het voor mekaar kan krijgen
hoop hier een antwoord te krijgen daar ik een beginneling ben met access en heb al talloze filmpjes bekeken op youtube maar kom er niet uit.
Hier komt mijn probleem: verschillende vrachtauto's op ons bedrijf krijgen door ons eigen monteur onderhoud en die vroeg mij om dat wat er nu op papier bijgehouden wordt via de computer te gaan doen en ben ik op het volgende uitgekomen.
Heb een vrachtwagen die krijgt op een Datum onderhoud bij een kmstand en dan komt het op die datum krijgt die vrachtauto smorgens onderhoud bv. remmen en banden en krijgt er ook een beurt bij,dat kan ik op 1 regel vastleggen maar nu komt het nu krijgt dezelfde auto s'middags nog een nieuwe band omdat die lek is gegaan dat wil ik ook in de tabel toevoegen maar dan vraagt ie ook om een remmen onderhoud en een beurt en dat zou ik allemaal in 1 tabel kunnen zetten maar dan krijg ik dus veel lege velden nu heb ik dat dus in 3 tabellen opgesplitst om dubbele data te voorkomen zoals datum,kmstand, maar krijg ze niet gekoppeld met mekaar.
heb al een koppeltabel geprobeerd maar dan vraagt ie toch om een remmenid en een beurtId als ik dat bijv. met die band in wil voeren. hoop dat iemand het zo snapt en mij even op weg kan helpen en uitlegt hoe ie het gedaan heeft. want bij die koppeltabel wat ik al bedacht had wou ik de Fk leeg laten maar dat krijg ik niet geregeld binnen access daar ik de velden niet op null kan zetten.

hier nog een klein voorbeeld:

Kenteken=>Datum=>km-stand=>Onderhoud --banden
--remmen
-- beurt

heb ook een access bestand toegevoegd om het een en ander hopenlijk te verduidelijken.
Alvast bedankt
met vriendelijke groet Patrick

 

[xps351]

Volgens mij zijn je tabellen al gekoppeld, in de zin dat je relaties hebt gelegd.
Wat je in ieder geval nog aan moet passen zijn de sleutels van de tabellen banden, remmen en beurt. Alleen de IDs als sleutel is voldoende om records uniek te maken.
Als je met koppelen bedoelt dat je geen gegevens in kunt voeren, dan zal je sowieso formulieren moeten maken. Dat is de manier om gegevens in te voeren.

 

[OctaFish]

Als je met koppelen bedoelt dat je geen gegevens in kunt voeren, dan zal je sowieso formulieren moeten maken. Dat is de manier om gegevens in te voeren

Ik heb de database niet bekeken, maar dit deel van het antwoord is pertinent fout. Mag je negeren. Of je gegevens in kunt voeren of niet in een query hangt van een aantal zaken af. In een query met Totalen bijvoorbeeld sowieso niet, maar in een Selectiequery kun je in beginsel altijd records invoeren. Tenzij je verkeerde relaties gebruikt, of verkeerde velden.

In beginsel is het heel simpel: kun je in de query records invoeren, dan kan je dat in een formulier (dat is gebaseerd op die query) ook. Kun je in de query géén records invoeren, dan kan dat in een formulier dat is gebaseerd op die query óók niet. Het formulier heeft daar dus geen enkele invloed op. Valt mij eigenlijk een beetje tegen van Peter dat hij dat niet weet .

 

[xps351]

Of je gegevens in kunt voeren of niet in een query hangt van een aantal zaken af.

Wie heeft het over een query gehad?

Als het over tabellen waartussen een op veel relaties bestaan gaat is het invoeren via hoofd- en subformulier(en) de enige logische weg.
Sowieso zouden gebruikers alleen formulieren te zien mogen krijgen. Dat valt me van jou nou weer tegen dat je dat anders ziet

 

[OctaFish]

Als het over tabellen waartussen een op veel relaties bestaan gaat is het invoeren via hoofd- en subformulier(en) de enige logische weg.

Nog zo’n antwoord waarvan je wel héél stellig iets beweert wat niet klopt. In ieder geval véél te kort door de bocht. En wie het over een query heeft gehad? Jij, door te beweren dat je goede koppelingen nodig hebt om gegevens in te voeren in een tabel. Dat is kul. Uiteraard heb je de juiste koppelingen (en vooral: de juiste instellingen daarvan) nodig. Maar dat staat echt los van het invoeren van gegevens.

Je laatste opmerking laat ik voor jou; heeft ook niets van doen met het vraagstuk. Ik ben (uiteraard) een groot voorstander van werken via formulieren; in mijn ogen de beste manier om gebruikers ‘af te schermen’ van de onderliggende techniek, en vooral om de processen zo soepel mogelijk te laten lopen.

Maar ik zal vandaag wel even naar de database kijken, wellicht krijgt TS dan een antwoord waar hij wat aan heeft .

 

[NoellaG]

Ik heb je voorbeeld genomen en de datastructuur wat aangepast. Ik heb de tabel Onderhoudstypes toegevoegd en dan heb je de tabellen Remmen en Banden niet meer nodig. Ik heb 2 voorbeeldformulieren aangemaakt zodat je kan zien hoe de nieuwe structuur werkt. Bekijk het voorbeeld even om te zien als je het goed vindt.
Trouwens ik heb ook de dubbelpunten uit de veldnamen gehaald. In veld- en andere objectnamen gebruik je best geen leestekens of spaties.

 

[PKlabbers]

Dank je wel allemaal alvast voor het meedenken. zeer zeker voor SQL DBA daar kan ik wel al wat mee, maar bedoelde eigenlijk iets anders daar onze monteur ook een computerleek is.
Maar heb zelf het 1 en ander weer in 2 datebases gezet om het te verduidelijken,en eigenlijk wou ik zo de formulieren ontwerpen en gebruiken alleen hier bedoel ik dus bij onderhouddata 1 kan ik wel alles invoeren in mijn formulier en opslaan maar als de monteur bv ziet dat hij bij een eerdere invoer fouten heeft gemaakt en wil veranderen en dan bedoel ik bv in beurt heeft hij een paar dingen ingevoerd en opgeslagen dan kan hij niet terug om bv nog banden of remmen aan te passen of toe te voegen daar ik dan een foutmelding krijg. Heb trouwens wel een JOIN gebruikt bij de Relaties leggen.
Dat kan dan weer wel in onderhouddata 2 alleen nu krijg ik dus een hoop lege velden elke keer daar als ik maar bv. 1 keer een beurt heb per jaar en wel meerdere keren banden vervangen.
Wil dus eigenlijk onderhouddata 1 gaan gebruiken daar ik dan de minste lege velden krijg. alleen weet niet hoe ik dan het beste de tabellen Beurt,Banden en Remmen moet gaan koppelen aan tabelonderhoud. misschien wel met een koppeltabel en daar een fk in maken van banden remmen en beurt alleen dan kan ik geen fk-waarde van null gebruiken want weet niet hoe ik dat moet instellen in access.
Hoop dat het zo een beetje duidelijker is jullie mij kunnen/willen helpen
alvast maar weer bedankt,
mvg Patrick

 

[PKlabbers]

Hierbij het begin wat ze nu in de werkplaats bij ons gebruiken wat ik aan het proberen ben om om te zetten in access.
misschien hebben jullie daar ook iets aan om mij te begrijpen.
gr. Patrick

 

[OctaFish]

Ik heb nog niet naar jouw nieuwe databases gekeken, was nog even bezig om de db van noella aan te passen (die heeft het al wat beter begrepen, maar nog niet helemaal correct). Dus je hoort het nog wat ik van de nieuwe databases vind .

 

[OctaFish]

Eigenlijk snel klaar: je nieuwe opzet zou ik zo snel mogelijk vergeten. De reden is simpel: je denkt nog steeds verkeerd. Ik zie bijvoorbeeld in beide databases dataredundantie: herhalende velden dus (Links as 1. Links as 2 etc). Dat moet je echt proberen te vermijden. En dat is ook simpel, als je de onderhouds handelingen in een aparte tabel (in het voorbeeld van noella is dat Onderhoudsregels) opslaat. Je geeft dus per onderhoud aan wat er moet gebeuren. Heb je vaste onderhoudsschema's, dan maak je daar een aparte tabel van, en kies je per onderhoudsbeurt een bijbehorend schema, zodat alle noodzakelijke handelingen met één klik in de onderhoudsbeurt zitten. Wat mij betreft zit je nu op een doodlopende weg.

Ik wil je graag helpen, maar niet met deze opzet .

 

[PKlabbers]

Nou Octafish ik geloof je meteen want ben al heel lang met deze opzet bezig, en die laatste dataredundantie had ik zelf voor lief genomen die vond ik al kleiner als in mijn 2de opzet maar goed als jij het op een andere manier ziet mag het van mij ook. alleen de monteur doet zijn onderhoud en dan is het de bedoeling dat hij invoerd wat ie gedaan heeft. Maar als je zou willen om het op een andere manier op te zetten en mij dat eens zou willen laten zien zou ik daar heel blij mee zijn. mvg. patrick

 

[OctaFish]

Dat kan dus prima vanuit de opzet die noella heeft gemaakt, waarbij je een tabel Onderhoud hebt, en een gekoppelde tabel OnderhoudGegevens. In die laatste leg je vast wat er precies gedaan is. Nadeel van zo'n constructie is dus dat je alle handelingen stuk voor stuk moet vastleggen. En ik kan mij voorstellen dat je voor specifieke onderhoudsbeurten een vast stramien afloopt dat gecheckt moet worden. En daar komt de tabel met schema's dus om de hoek kijken.

E.e.a. hangt dus helemaal af van jullie werkwijze en procedures. De protocollen dus. In je Excel document (althans: het formulier dat je in bericht #8 meestuurde) werk je al min of meer met een vaste lijst die afgewerkt moet worden. En dat is dus precies wat ik bedoel met 'schema's'. Leg die vast, toon die op een formulier met ja/nee velden en laat de monteur afvinken wat-ie gedaan heeft. Met aanvullend memovelden voor de nadere uitleg.

 

[PKlabbers]

Ik vond het idd een nadeel dat je alle handelingen stuk voor stuk moet vastleggen(maar wel een optie) via zo'n formulier wat ik al meestuurde is dat makkelijker en
overzichtelijker dat je niks vergeet maar goed als dat niet anders kan want een beurt krijgen ze maar 1x per jaar en banden en remmen komen vaker voor dus. snap alleen nog niet wat je bedoelt met schema's vast leggen en die tonen op een formulier dacht eigenlijk dat ik dat zo wel gedaan had alleen hij hoeft ze maar in te vullen met G-goed,C-Gecontroleerd,V-Vervangen in plaats van afvinken. maar misschien zou je mij het eens in een voorbeeld kunnen zetten als je dat wilt kan ik er na de kerst week eens na kijken en hier op terugkomen als ik weer s'avonds onderweg en alleen ben. ben namelijk zelf chauffeur met dit als een hobby om te ontdekken en s'avonds als ik alleen ben wat te doen heb .
Alvast bedankt voor de genomen moeite.
Iedereen fijne feestdagen en een goeie roets in 2024

Gr. Patrick

 

[OctaFish]

Wat ik met ‘schema’s bedoel is dat je een aantal vaste onderdelen van een bepaalde onderhoudsbeurt in een aparte tabel opslaat. Wat je nu hebt, is een lijst (tabel) met activiteiten, zoals olie verversen, remmen controleren, bougies vervangen en ruitenwissers vervangen. Die staan nu allemaal op je formulier. Dat is onoverzichtelijk, en in mijn ogen onhandig. Dat ziet er dan zo uit:
Activiteit —> onderhoudsbeurt.
Stel dat je (heel erg versimpeld dus) twee soorten onderhoudsbeurten hebt: kleine beurt en grote beurt. De kleine beurt bestaat uit olie verversen en remmen controleren, en de grote beurt uit olie verversen, remmen controleren, bougies vervangen en ruitenwissers vervangen.
Dan maak je een aparte tabel met onderhoud schema’s waarin je de tabellen Activiteiten koppelt aan een onderhoudsbeurt. Dan krijg je, in dit simpele voorbeeld, 6 records met de volgende combinaties:
olie verversen - Kleine beurt
remmen controleren - Kleine beurt
olie verversen - Grote beurt
remmen controleren- Grote beurt
bougies vervangen- Grote beurt
ruitenwissers vervangen- Grote beurt

Op je formulier Onderhoud kies je dan een schema, dus Grote beurt of Kleine beurt. In het subformulier zie je dan de bij die beurt behorende activiteiten staan. Je weet dus precies wat er moet gebeuren bij een specifieke onderhoudsbeurt.
Je schema is dan dus:
Activiteit —> Schema —> onderhoudsbeurt.
En dit systeem kun je dus zo flexibel inrichten als je wilt.

Zo zou ik het dus doen .

 

[NoellaG]

Daar heb je geen extra tabel voor nodig hoor, ik heb de onderhoudstypes zo opgesteld dat je via het type alle regels met een subtype in één keer kan toevoegen. Gewoon een knop op het fromulier zetten die via een append query of zo in één keer de regels aanmaakt met alle subtypes die tot één type behoort. Veel eenvoudiger dan met extra tabellen te werken. Ik zal na kerstmis dat in mijn voorbeeldje toevoegen. Maar voor het moment heeft de kerstkalkoen al mijn aandacht nodig.
Voor iedereen: happy X-mas en een gelukkig 2024.

 

[OctaFish]

Toen ik schreef dat jouw oplossing niet helemaal jofel was, had ik het dus over die tabel met onderhoudstypes. Die kan echt veel slimmer. Kijk daar vooralk naar als je gaat knutselen! (of zoek het op in mijn cursus )

 

[NoellaG]

om te beginnen knutsel ik echt niet als het om data architectuur gaat , dit is mijn beroep dat ik al meer dan 20 jaar met veel succes uitoefen voor kleine, middelgrote tot zeer grote bedrijven. En de oplossing die ik hier gegeven heb is een goede basis voor applicaties voor truckbeheer gebleken (weliswaar niet in access gemaakt). Mijn ervaring: KISS (Keep It Simple Stupid) werkt, en ingewikkelder is meestal niet slimmer.

 

[OctaFish]

En de oplossing die ik hier gegeven heb is een goede basis voor applicaties voor truckbeheer gebleken

Nee dus, dat ben ik totaal niet met je eens. Maar ja, dat is dan het verschil tussen iemand die wél graag met Access werkt en iemand die liever met zwaarder spul werkt denk ik. Ik zal mijn oplossing uiteraard ook graag delen hier. En dan zul je het ongetwijfeld met me eens zijn dat die van mij beter is ').

 

[NoellaG]

Zoals beloofd een voorbeeld met de mogelijkheid om alle regels van een bepaald type snel toe te voegen. Om te vermijden dat je moet gaan programmeren heb ik het met een macro opgelost. Op het formulier staat nu een keuzelijst met alle bestaande types waaruit je kan kiezen. Via de knop ernaast kan je alle subtypes ervan in één beweging toevoegen. Het is zeker geen volledig afgewerkte oplossing, maar een aanduiding hoe het kan opgelost worden.