probleem met toevoegquery

[PFL]

Hallo Ann,

Ik heb nog eens wat meer in detail naar de tabellen en formulieren in jouw database gekeken. Op basis daarvan denk ik dat je zoiets als dit voor ogen hebt, klopt dat? (zie bijlage)

Het gaat met name om het formulier GroepJaarPeriode, bestaande uit een hoofdformulier en twee subformulieren, waarin je elke gewenste combinatie van groep, jaar, periode, lesgevers en dansers kunt maken.

En op basis daarvan kun je dan weer nieuwe tabellen, queries en formulieren maken voor de lesdagen per groep en de aanwezigheidsregistratie.

Ik heb trouwens de tabel 'Leerlingen' hernoemd in 'Relaties' en daar heb ik drie nieuwe velden aan toegevoegd waarin je kunt aanvinken of iemand Danser, Lesgever of Bestuurslid is of een combinatie daarvan.

 

[OctaFish]

Ik heb trouwens de tabel 'Leerlingen' hernoemd in 'Relaties' en daar heb ik drie nieuwe velden aan toegevoegd waarin je kunt aanvinken of iemand Danser, Lesgever of Bestuurslid is of een combinatie daarvan.

Dat lijkt mij een slechte zaak; dat hoort ofwel een veld met meervoudige waarden te zijn (kun je in een query weer uitsplitsen) ofwel een aparte gekoppelde tabel. Dit schoffelt de normalisering onderuit.

 

[PFL]

Hmm, ik had me wat minder sterk uitgedrukt in dit geval maar OK, in principe heb je gelijk

Dan wordt het een aparte tabel want een veld met meervoudige waarden levert een query en een formulier op waarin elke waarde een apart record krijgt, en dat is natuurlijk niet handig. Of ik moet ergens iets fout doen.

Zie het formulier 'RelatiesMVK' in de bijlage. De eerste relatie 'Dewitte' is zowel danser als lesgever en krijgt daarom 2 records, de tweede relatie 'Goossens' heeft 3 functies en krijgt dus 3 records, etc.

Ondertussen blijft het overigens erg stil in België...

 

[PFL]

Ik had weinig tijd vanmorgen omdat ik weg moest en heb daardoor wat te snel conclusies getrokken. Als je het 'gewone' veld selecteert in de query i.p.v. het 'subveld' om het zo maar even te noemen dan gaat het wel goed. In dit geval dus 'Functie' i.p.v. 'Functie.Value' (of 'Functie.Waarde' wellicht in een Nederlandse versie van Access).

Zie RelatiesMVKqry2 en RelatiesMVK2 in de bijlage.

Maar dat ik het nou zo geweldig vind zo, mwah...

 

[OctaFish]

Hmm, ik had me wat minder sterk uitgedrukt in dit geval maar OK, in principe heb je gelijk

Zachte heelmeesters maken stinkende wonden . Ik polariseer inderdaad wel eens, maar daarmee maak je wel duidelijk dat er een probleem is. Als ik het softie-softie breng zou je allicht de indruk kunnen krijgen dat een oplossing best wel ok is maar misschien beter kan, terwijl dat dus in mijn (al dan niet gevorderde) ogen dus echt niet het geval is.
Maar je vraagt je inderdaad af of we nog wel voor TS bezig zijn, of om onze scores op te hogen .

 

[annw]

Heel erg bedankt aan iedereen voor de informatie, ik probeer het allemaal te bekijken en te begrijpen. ik laat jullie volgende week weten hoever ik ermee geraakt ben !

 

[PFL]

OK, succes ermee!

Hierbij de laatste versie van de database (d.w.z. mijn laatste versie) waarin ik de velden Danser, Lesgever en Bestuurslid in de tabel 'Relaties' heb vervangen door het veld 'Functie' waarin je meerdere keuzes kunt maken. Ja, toch maar wel bij nader inzien . Het heeft wat voordelen t.ov. een aparte tabel.

De query en het formulier voor de relaties zijn dienovereenkomstig aangepast.

Verder heb ik niets gewijzigd.

 

[PFL]

Ik heb nu ook de lesdagen toegevoegd aan het formulier GroepJaarPeriode (zie bijlage).

Op basis van wat er nu m.b.v dit formulier is vastgelegd in de onderliggende tabellen zou het toch mogelijk moeten zijn om een tabel met een aanwezigheidsregistratie te maken. Dus gewoon simpel een lijstje met de lesgevers en dansers, per groep en per lesdag, waarop afgevinkt kan worden wie er wel en niet aanwezig waren.

Ik kom daar echter niet uit. Wie kan mij op weg helpen? Bij voorkeur (indien mogelijk) zonder VBA-programmeerwerk zodat Ann (TS) en ik het allebei ook begrijpen

 

[OctaFish]

Ik zit zo eens naar je relaties te kijken, en ik raak daar erg door in de war; geen idee eigenlijk wat je aan het bakken bent zo. Persoonlijk denk ik dat je het zo niet moet doen. Ik wacht dus wel even op de laatste versie die Ann gaat posten .

 

[PFL]

Wat mankeert er aan de relaties dan? Als je dat er niet bij vermeld dan leer ik er niks van. Bovendien verwacht ik niet dat Ann met iets beters komt (ook niet met iets slechters wellicht, haha!).

Maar ik vermoed dat je mij eigenlijk niet wilt helpen.

 

[OctaFish]

Tabel Dagen? Weg ermee. Tabel Jaren? Weg ermee. Tabel GroepLesgegevens en tabel GroepDansers koppelen aan zowel Relaties en GroepJaarPeriode? I don't get it.... Een cursussen database zou m..i. moeten bestaan aan uit Leerlingen (in dit geval is dat Relaties met meerdere functies), Cursussen (wat kun je boeken) en een lesrooster Welke cursus draait in welk jaar op welke dagen). Vervolgens koppel je de leerlingen en docenten aan het betreffende cursusblok. Dat vind ik allemaal dus niet terug in je veel te ingewikkelde opzet

 

[PFL]

Bedankt, daar hebben we meer aan. Probeer je af en toe wat meer te verplaatsen in amateurs zoals ik, als je wilt. Jij hebt als professional al heel vaak met dit bijltje gehakt maar ik niet. En deze site lijkt me toch met name bedoeld voor amateurs dus dan zul je soms wat meer geduld moeten hebben en wat meer uit moeten leggen.

Ik heb misschien de tabellen in Anns originele database wat te veel als basis genomen. De tabel Jaren is alleen maar bedoeld om het cursusjaar aan te geven. Eigenlijk alleen maar een stukje extra informatie dus bij de groepen en wat verder geen invloed heeft op de werking van de database lijkt mij.

Met de tabel Dagen ben ik ook niet zo happy en ik had in een andere versie inderdaad een tabel Lessen (met een lesrooster) maar toen ik vastliep op de aanwezigheidsregistratie heb ik het anders geprobeerd. Vergeefs dus.

Ik zal het eens proberen op de manier die jij aangeeft

 

[annw]

het is ook omdat ik altijd vastliep dat al die tabellen en al die queries er gekomen zijn, om tot een oplossing te komen. die jaren zijn er gekomen om de groepen van dit jaar te kunnen selecteren. de periodes zijn er gekomen omdat sommigen voor een heel jaar betalen, en anderen voor een half jaar. dit leek voor mij een oplossing om tegen eind januari (einde eerste periode) enkel de mensen die niet voor een heel jaar betaald hebben te kunnen aanschrijven. de dagen zijn er gekomen omdat ik anders vast zat met de aanwezigheden. als ik gewoon een datum invulde op mijn formulier met de aanwezigheden, bleef dit vak leeg, daarom heb ik een tabel gemaakt met de dagen van de lessen. als ik het op die manier deed, stond de datum in het vak, en kan ik die wegschrijven in mijn tabel. ik kwam dit probleem op verschillende plaatsen tegen (ook bij het saldo van de rekeninguittreksels dat leeg blijkt te zijn, ik had dit voor in de verkoop van de kledij dat er vakken leeg bleken te zijn. voor deze rede zijn er verschillende tabellen in het leven geroepen die misschien niet echt noodzakelijk zijn) ondertussen heb ik al begrepen dat dit probleem komt omdat mijn formulieren niet op basis van tabellen gemaakt zijn.
ik had op voorhand geen idee waar ik naartoe wilde, en ben gewoon vertrokken met de excel tabel adressen die er op de dansschool bestond, en heb daarop verder gewerkt. elke keer als ik iets aan de praat kreeg, was ik blij dat het lukte, en besloot ik om er nog een stukje bij te maken. ik zie nu ook wel in dat dit niet de juiste manier is om aan iets te beginnen
Op dit punt kan ik wel al aangeven wat ik eigenlijk met deze database wil bereiken : ledengegevens bijhouden en bijwerken, indeling maken van de groepen (elk jaar opnieuw, zodat er een historiek is van wie welk jaar in welke groep danste), de bankverrichtingen bijhouden zodat de boekhouding van de VZW hieruit kan afgeleid worden (later ook nog de inkomende facturen hieraan koppelen), de aanwezigheden van de dansers en de lesgevers bijhouden (scannen) en hieruit ook de vergoeding van de lesgevers berekenen, de stock van de kledij bijhouden en 1x per jaar de verkoop van de kledij bijhouden (wat is in stock, wat dient bestelt te worden, wie heeft wat gekocht)
veel van de dingen die ik wil bereiken heb ik ondertussen (op mijn manier) aan de praat gekregen (via waarschijnlijk veel te veel queries waardoor ik zelf de bomen door het bos niet meer zie), maar ik heb wel besloten om alles te hermaken op de manier die jullie voorstellen (echt van nul herbeginnen en dan proberen te begrijpen waarom jullie het zo doen)
wish me luck
alvast bedankt voor de tijd die jullie hierin willen steken
groetjes uit het zonnige belgië
ann

 

[PFL]

Bedankt voor de toelichting Ann. Ik snap hoe het allemaal gegaan is.

Ik ben nog steeds bereid om tijd te steken in jouw database en ik hoop dat de 'grote meester' (om hem zo maar even te noemen ) dat ook is, ondanks dat we allebei maar 'amateurtjes' zijn, want we zullen hem wel nodig hebben. Maar hopelijk met zo weinig mogelijk programmeerwerk want wat mij betreft heb je er niks aan als je straks een database hebt waarvan je de helft niet begrijpt en die je dientengevolge niet goed kan onderhouden, uitbreiden of wijzigen. Jij hebt gewoon een database nodig die doet wat je zojuist allemaal hebt beschreven en die hoeft niet helemaal strak volgens de professionele regels gemaakt te zijn en super efficiënt te zijn. Je runt een dansschool tenslotte en geen multinational (met alle respect overigens want het is nog best ingewikkeld).
Maar goed, dat is mijn mening. Octafish denkt er wellicht anders over.

Ik had nog één vraagje op dit moment: hebben de groepen gedurende een periode altijd dezelfde lesgevers of kan dat per les verschillen? Bijv. door ziekte of vakantie of gewoon omdat ze niet aldoor dezelfde groep willen hebben.

 

[annw]

in principe blijft dit gedurende het hele jaar hetzelfde, maar als er natuurlijk iemand langdurig ziek is ofzo kan het wel dat het verandert

 

[OctaFish]

Bedankt, daar hebben we meer aan. Probeer je af en toe wat meer te verplaatsen in amateurs zoals ik, als je wilt. Jij hebt als professional al heel vaak met dit bijltje gehakt maar ik niet. En deze site lijkt me toch met name bedoeld voor amateurs dus dan zul je soms wat meer geduld moeten hebben en wat meer uit moeten leggen.

Ik heb in bericht #18 al aangegeven waarom de opzet met de tabellen Jaren en Dagen niet goed is. We zijn nu 15 berichtjes verder, en inhoudelijk blijft het toch een beetje daar op hangen .
Daarnaast ben ik mij er volledig van bewust dat de vraagstellers vaak amateurs zijn en dus niet altijd weten hoe ze iets aan moeten pakken; van iemand die een antwoord geeft mag je verwachten dat hij/zij weet waar hij/zij het over heeft. En dat de antwoorden dus redelijk kloppen. Toch?
Overigens vind ik dat je je antwoorden heel goed en uitgebreid opschrijft; daar schijnt het bij mij volgens sommigen nog wel eens aan te schorten. (ben ik het uiteraard niet mee eens )

De vraag zelf is volgens mij ook behoorlijk uit het zicht geraakt dan wel opgelost, en het lijkt mij beter om de vraag zelf af te sluiten en voor een nieuw probleem een nieuwe vraag te maken.

maar ik heb wel besloten om alles te hermaken op de manier die jullie voorstellen (echt van nul herbeginnen en dan proberen te begrijpen waarom jullie het zo doen)

Het is inderdaad nooit een goed plan om alles vanuit Excel rechtstreeks te vertalen naar Access; je stapt juist over van Excel naar Access omdat Excel niet voldoet voor jouw werkproces.
Behalve het omschrijven van de taken die je wilt kunnen uitvoeren met de database, is het ook belangrijk (veel belangrijker eigenlijk) dat je de processen goed omschrijft: dus het wat is net zo belangrijk als het he , wie en wanneer.

Beschrijf alles eerst in gewone tekst, hoe stom dat er ook ogenschijnlijk uit mag zien. Zinnen als:

Een ingeschreven persoon kan zich inschrijven voor één cursus tegelijk. Een bestuurslid mag zich voor twee cursussen inschrijven en krijgt 20% korting op de tweede cursus. De database moet elke maand een maandfactuur versturen naar de ingeschreven leden.

Heeft hele andere consequenties voor de database als

Een ingeschreven persoon kan zich inschrijven voor meerdere cursussen tegelijk. Een bestuurslid mag geen andere rol vervullen. Een bestuurslid mag zich ok niet inschrijven voor cursussen. Een cursusdeelnemer mag alleen aan een cursus meedoen als er vooraf (pin, cash) is betaald. Aan het eind van het boekjaar moet een overzicht van alle betalingen worden gemaakt.

Kortom: hoe duidelijker je alle wensen en werkprocedures en werkprocessen omschrijft, hoe duidelijker het wordt hoe de database er uit moet komen te zien! We noemen dit: een Functioneel Ontwerp (FO). Op basis van het uitgewerkte FO maak je een ER diagram (Entiteit-Relatie) en daarin staan dan de tabellen die je nodig hebt om alles uit het FO te vertalen naar de processen. Heb je die tabellen, en kun je alles opslaan zoals je het hebt bedacht (bedenk hierbij: Garbage In = Garbage Out) dan ga je pas aan je formulieren en queries werken.
Hoe vaak ik al (hier op Helpmij bijvoorbeeld) gezien heb dat er precies andersom wordt gewerkt, wil je echt niet weten .

 

[OctaFish]

Maar hopelijk met zo weinig mogelijk programmeerwerk want wat mij betreft heb je er niks aan als je straks een database hebt waarvan je de helft niet begrijpt en die je dientengevolge niet goed kan onderhouden, uitbreiden of wijzigen.

Een goede database kan doorgaans niet zonder dat er programmeerwerk in zit. Je kunt het maken van een database, hoe graag Microsoft ons ook anders wil doen geloven, niet maken zonder gedegen kennis van (niet alleen) Access en databases. Jij kunt ongetwijfeld een prima boterham snijden, en wellicht kun je ook nog prima een vis fileren. Toch ben ik enigszins terughoudend om jou een open hart operatie te laten uitvoeren op mijn vriendin. Tenzij je een chirurg bent natuurlijk . Wat ik bedoel te zeggen: het hebben van een stuk gereedschap betekent niet gelijk dat je er ook gelijk goed mee kan werken; daar heb je tijd voor nodig om dat te leren. En dat geeft natuurlijk totaal niet; Access is wat mij betreft één van de leukste programma's om te leren. Juist omdat er zoveel bij komt kijken!

@Ann: Als je een goede database nodig hebt (en voor bedrijfsvoering is dat zo'n gek idee niet) en je kunt hem niet zelf maken, dan zou ik zeggen: huur iemand in die dat wél kan. Niet zelf gaan prutsen. Dat doe je tenslotte (hoop ik) ook niet bij andere vakken waar je geen vetrstand van hebt.
Wil je het wél leren, dan ben je hier op de juiste plek, en helpen we je uiteraard graag de goede kant op!
Overigens herhaal ik dan wel mijn opvatting dat je beter voor elke vraag die je tegenkomt een nieuw topic kunt maken; je krijgt ongelovelijke vervuiling in een draadje (we zitten nu al ruim boven de 30 berichtjes) en dat maakt de duidelijkheid er niet beter op.

 

[PFL]

Ik heb in bericht #18 al aangegeven waarom de opzet met de tabellen Jaren en Dagen niet goed is. We zijn nu 15 berichtjes verder, en inhoudelijk blijft het toch een beetje daar op hangen .

In bericht #18 zeg je "Een jaartal kun je altijd uit een datum herleiden" en dat heb ik inderdaad ergens voorbij zien komen in jouw cursus, maar dat lijkt me in dit geval niet handig. De jaren staan in dit geval namelijk voor seizoenen en die lopen niet van 1/1 t/m 31/12 maar van september t/m juni. Dus bijvoorbeeld 2 maart 2016 valt onder seizoen 2015, maar 2 september 2016 valt onder seizoen 2016.
Maar goed, is verder niet zo belangrijk en daar moeten we inderdaad niet op blijven hangen.

Daarnaast ben ik mij er volledig van bewust dat de vraagstellers vaak amateurs zijn en dus niet altijd weten hoe ze iets aan moeten pakken; van iemand die een antwoord geeft mag je verwachten dat hij/zij weet waar hij/zij het over heeft. En dat de antwoorden dus redelijk kloppen. Toch?

Ik geef toe dat ik niet altijd precies weet waar ik het over heb. Maar dat kan al snel vergeleken met jou, haha!

Overigens vind ik dat je je antwoorden heel goed en uitgebreid opschrijft;

Dankjewel!

Kortom: hoe duidelijker je alle wensen en werkprocedures en werkprocessen omschrijft, hoe duidelijker het wordt hoe de database er uit moet komen te zien! We noemen dit: een Functioneel Ontwerp (FO). Op basis van het uitgewerkte FO maak je een ER diagram (Entiteit-Relatie) en daarin staan dan de tabellen die je nodig hebt om alles uit het FO te vertalen naar de processen. Heb je die tabellen, en kun je alles opslaan zoals je het hebt bedacht (bedenk hierbij: Garbage In = Garbage Out) dan ga je pas aan je formulieren en queries werken.
Hoe vaak ik al (hier op Helpmij bijvoorbeeld) gezien heb dat er precies andersom wordt gewerkt, wil je echt niet weten .

Ik ben het hier zeker wel mee eens (alhoewel ik een ER diagram wat ver vind gaan in dit geval).
Het probleem is echter dat als je Access nog niet zo goed kent, het lastig is om te bepalen welke tabellen je allemaal nodig hebt en vooral wat er dan precies in die tabellen moet staan en hoe alle gegevens aan elkaar gekoppeld moeten worden.
M.a.w.: je moet eerst goed weten hoe Access werkt vóórdat je een fatsoenlijk FO kan maken. En Access leer je alleen goed kennen door er mee te werken en dingen uit te proberen. Met vallen en opstaan dus. Zoals Ann en ik nu doen .

 

[PFL]

Een goede database kan doorgaans niet zonder dat er programmeerwerk in zit. Je kunt het maken van een database, hoe graag Microsoft ons ook anders wil doen geloven, niet maken zonder gedegen kennis van (niet alleen) Access en databases.

Als je met gedegen kennis bedoelt op professioneel niveau of in ieder geval op hoog niveau dan ben ik het niet helemaal met je eens.
Robben en Van Persie kunnen beter voetballen dan de meeste amateurs maar dat wil nog niet zeggen dat die amateurs niet kunnen voetballen en geen wedstrijden kunnen winnen. Het gaat alleen wat minder professioneel.
Niettemin geloof ik direct dat er voor Anns database wel wat programmeerwerk nodig is.

@Ann: Als je een goede database nodig hebt (en voor bedrijfsvoering is dat zo'n gek idee niet) en je kunt hem niet zelf maken, dan zou ik zeggen: huur iemand in die dat wél kan.

Die jongens (zoals jij... ) zijn heel duur, weet je dat wel?

 

[PFL]

Is dit beter?