kom maar niet verder met mijn database

[martijnverdaas]

Hallo mensen,

IK ben druk aan het proberen mijn database progje aan de praat te krijgen voor mijn lessen.
Nu loop ik echt vast en hoop dat een paar mensen mee willen kijken en mij echt even opweg kunnen helpen zodat ik weer verder kan.

http://www.allezkidz.nl/test.rar

Ik wil het allemaal graag zelf doen, maar ik kom er niet meer uit.

even een paar probleempjes waar ik tegen aanloop, en waarmee ik niet verder kom

• frmLeerling
  
  het veld leeftijd probeer ik te vullen met dlookup
  
  

  =DLookUp("[Leeftijd]";"[qryLLVerjaardagen]")

  Ik zeg hier eigenlijk dat ik in dit formulier de waarde wil zien van een veld uit de qry [qryLLVerjaardagen]
  
  Ik heb ook geporbeert een creteria eraan te koppelen, maar dan loopt ik steeds tegen een foute code aan. Deze code geeft geen foutmelding, maar ook geen waarde weer?

• en dan de inschrijfknop
  
  Deze knop opent [frmclubaanmeldingen]
  
  nu wil ik graag dat hij dat pas doet na het ingeven van de waardes in de twee cbo's die er voorstaan. Dus wanneer deze nog leeg zijn hij een melding geeft kies club!
  
  als hij het formulier opent moet hij div. velden automatisch invullen.
  
  1. bovenaan het seizoen weergeven als txt
  2. LLID moet hij meenemen omdat je een cursus inschrijft vanuit het leerling formulier
  3. club had je ook reeds gekozen dus die moet ook ingevuld worden.
  4. vanuit de clubcode wil ik dan ook de velden niveau en type vullen net als de standaard betaal methode voor deze club. deze worden ingegeven in frm [frmclubs]
  
  5. bovenaan wil ik graag de volledige naam van de leerlingen c.q. paar dat ingeschreven is.
  
  Ik heb nu een qry [qryLLVerjaardagen] waar de naam van de eerste persoon prima naar voren komt. maar ik mis wanneer ik een paar inschrijf de andere persoon.
  
  ik zou graag willen dat de weergegeven naam als volgt eruit ziet.
  
  voorletters of voornaam (beide zullen nooit gevuld worden) evt. tussenvoegsel achternaam. En wanneer het vakje paar aangevinkt staat eerst een & (en teken) en dan hetzelfde riedeltje voor de partner.
  het veld aanhef hoeft niet mee in deze. Het is meer uit gewoonte dat ik deze erin geplaatst heb. Maar het is volgens mij aardig oubollig.
  
  6. het vinkje bij paar moet ook mee ingevuld worden.
  

Het is heel wat. maar ik zie door de bomen het bos niet meer. hoop na deze forse duw in de rug weer verder te kunnen.

groetjes, Martijn

 

[OctaFish]

Ik dacht dat ik gisteravond nog een antwoord had gepend, maar ik zie 'm niet meer terug; waarschijnlijk iets fout gegaan bij het opslaan. Overdag kan ik de db niet openen, dus even uit het hoofd nog een keer het antwoord van gisteren... Wel wat korter
1. Je DLookup die je gebruikt gaat zowiezo niet werken omdat je geen criterium meegeeft; DLookup kan in een formulierveld maar één waarde laten zien, en niet meer. Door geen criterium mee te geven in een query met meerdere records, krijg je dus niks. Je moet dus een criterium gebruiken.
1a. Maar waarom DLookup gebruiken? In je query gebruik je de functie DateDiff om de leeftijd te berekenen; waarom gebruik je die functie niet op je formulier? Werkt prima! D.w.z.: je krijgt een uitkomst, maar dat is niet correct in een hoop gevallen. Bedenk maar eens waarom jouw formule een beetje kort door de bocht is
2. De inschrijfknop zou ik uitschakelen, en aanzetten op basis van je twee keuzelijsten; als in beide keuzelijsten een waarde is gekozen, mag de knop weer actief worden. Voorkomen is beter als genezen.
2a. Een tweede formulier vullen met waarden uit een eerste doe je door bij het openen de parameter OpenArgs te vullen met de over te zetten waarden. Op het tweede formulier lees je de OpenArgs weer uit, en vul je de velden.
5. (je nummering is een beetje inconsequent) is een kwestie van een formule maken die de velden combineert: =[Veld 1] & " " & =[Veld 2] & " " & =[Veld 3]
5a. Los je op met een IIF. Check [Veld 1] (met [Veld 1] Is Null) en doe dan [Veld 2], anders [Veld 1]. Overigens zou ik niet laten kiezen tussen voorletters of voornaam, maar ze gewoon beide laten vullen indien mogelijk. Veel beter.

In het algemeen: wat een oerwoud aan tabellen! Ik zie ook door jouw bomen geen bos meer; ik denk dat ik zo'n database met heel wat minder tabellen zou kunnen maken. Bovendien is er een aantal niet goed te koppelen (deels door ontbrekende records, maar veel belangrijker: er zijn tabellen gekoppeld op basis van niet-overeenkomende veldtypen, en dat is natuurlijk uit den boze).

 

[OctaFish]

In je andere draadje komt MadRef tot dezelfde conclusie: de db kan heel wat simpeler. Of je zijn opzet moet overnemen is daarbij nog een vraag, want daar zie ik ook nog wel een paar design foutjes in zitten. Maar daar gaat het hier niet over; jouw db is qua opzet volgens mij in ieder geval niet helemaal goed uitgewerkt. Daar bovenop ben je in mijn ogen iets te snel met de formulieren aan de slag gegaan. Als de structuur namelijk niet goed genoeg blijkt te zijn, dan heb je een hoop werk voor niets gedaan.

 

[madref]

@OctaFish: Welke design foutjes zie je dan in mijn database?

Ben gewoon nieuwsgierig wat jij anders zou doen.

 

[OctaFish]

Er is 1 tabel vooral die nogal wat gefronsde wenkbrauwen opleverde: de tabel [tbl_Teams]. Als je naar deze gegevens kijkt:

Team_ID Team_Sei_ID Team Geboortejaren Leeftijden Afkorting Geboortejaar van Geboortejaar tot Team_Volgorde Team_Actief
61 6 Mini's (U8) 2004 of later 7 jaar of jonger M 2004 2011 60 WAAR
62 6 Welpen (U10) 2002 en 2003 8 en 9 jaar W 2002 2003 61 WAAR
63 6 U12-team 2000 en 2001 10 en 11 jaar U12 2000 2001 62 WAAR
64 6 U14-team 1998 en 1999 12 en 13 jaar U14 1998 1999 63 WAAR
65 6 U17-team 1995, 1996 en 1997 14,15 en 16 jaar U17 1995 1997 64 WAAR

dan is die nauwelijks te onderhouden lijkt mij. Niet alleen is het veld [Team_Geb_jaar] volslagen niet-gestandaardiseerd, ook de velden [Team_Geb_van] en [Team_Geb_tot] zijn ofwel overbodig (dubbelop t.o.v. [Team_Geb_jaar]) maar ze zijn zo ook onbruikbaar, omdat een leeftijdscategorie vast moet liggen op basis van leeftijd, en niet op basis van jaartal. Tenzij een lid levenslang lid is van bijvoorbeeld de groep <Mini's (U8)>, omdat hij/zij geboren is tussen 2004 en 2011. Over 20 jaar is die persoon nog steeds geboren tussen 2004 en 2011 namelijk. En mijn persoonlijk inschatting is dat die persoon dan minstens 22 is, en dan is het een beetje oneerlijk als hij nog steeds tegen teams moet spelen die wèl onder 8 zijn .
In de tabel [tbl_Subcategorie] heb je een veld [SUB_Omschrijving] met daarin 3 contributierecords (Contributie seizoen 2008-2009 t/m Contributie seizoen 2010-2011). Lijkt mij ook een slechte zaak, één record voor contributie is genoeg. Desnoods gebruik je een historietabel als je van sommige velden de historie wilt bewaren. Verder zit er nogal wat redundantie in de tabel [tbl_Administratie] met al die contributiegegevens en aanmaningsdatums. Dus daar kun je met een paar extra tabellen nog wel winst boeken. De tabel [tbl_AdresStickers]? Adressen heb je al opgeslagen. Zie ik geen functie voor; weg er mee dus. Tabel [tbl_Personen_Leden]? Geen idee wat je daar mee wilt; je hebt al een tabel [tbl_Personen]. Weg ermee? Tabel [tbl_Seizoenen]: [Sei_Van] en [Sei_Tot] staat ook al in [Sei_Periode]. Dataredundantie dus. En weg ermee!
Dat zijn zo de eerste indrukken. Wellicht heb je moverende redenen om het zo te doen, maar die weet ik uiteraard niet.

 

[madref]

Beste Michel,

Dank je wel voor het kijken naar mijn database en je opmerkingen.
De tabel waar jij zoveel moeite mee hebt is heel makkelijk uit te leggen.
Doordat de leeftijdscategorieën per seizoen nog al eens wisselen van geboortejaren heb ik het zo flexibel mogelijk gemaakt.
Het veld [Team_Geb_jaar] is er puur en alleen voor de overzichtelijkheid tijdens het selecteren van het team waarin een lid DAT seizoen speelt.
De velden [Team_Geb_van] en [Team_Geb_tot] geven de grens van een team aan. Meestal 2 jaar, maar soms ook 3 jaren.

De tabel [tbl_AdresStickers] is een hulp tabel die ik gebruik voor het samenstellen van de adresstickers. Er kunnen meerdere leden van een vereniging op één adres wonen en dat scheelt dan weer geld. Vervolgens gebruik ik die tabel ook om een mailmerge toe te passen.

In de tabel [tbl_Subcategorie] heb je een veld [SUB_Omschrijving] met daarin 3 contributierecords (Contributie seizoen 2008-2009 t/m Contributie seizoen 2010-2011).

Dit zijn boekingsposten immers kun je in een bepaald seizoen ook nog betalingen krijgen van eerdere seizoenen. Als je dit op een hoop gooit dan ziet de boekhouder niet meer het verschil wanneer je wat hebt binnengekregen aan betalingen.

Verder zit er nogal wat redundantie in de tabel [tbl_Administratie] met al die contributiegegevens en aanmaningsdatums.

In der tijd dat ik dit heb gemaakt wist ik niet hoe ik het probleem van de brievenadministratie moest maken en daarom heb ik indertijd alles aan de tabel tbl_Administratie gehangen. Immers ieder lid krijgt aan het begin van het seizoen een contributiebrief. En voor een eventuele deurwaarder moet je ook de stukken en de stappen kunnen laten zien om je contributie te innen. Verder wordt deze tabel gevuld door de verschillende formulieren binnen het database. Dit is DE tabel waarom het draait in dit database.
Heb je nog tips hoe ik dit anders zou kunnen oplossen met de brievenadministratie?

[tbl_Personen] is er voor om alle persoonsgegevens te registrenen van iemand die iets voor de vereniging doet.
Deze persoon kan een lid zijn en/of een donateur of iemand zijn waarvoor de vereniging een dienst heeft geleverd (FaktuurAanDerde (FAD)).
tbl_Persoon_Leden -=> zijn de extra lid gegevens
Zo ook bij de donateurs en de FAD.

Ik hoop dat ik je zo een beetje inzicht heb gegeven in de redenaties achter bepaalde tabel en de gemaakte keuzes.