Hulpvraag

  • Onderwerp starter Onderwerp starter jog
  • Startdatum Startdatum
Status
Niet open voor verdere reacties.

jog

Gebruiker
Lid geworden
4 mrt 2009
Berichten
69
Hallo allemaal,

na uren "zelfopzoekingswerk" en "zelfuittestingsaanpassingen" resulterend in frustratie en uiteindelijk hoofdpijn leg ik alle hoop in de handen van de alwetende forumbezoeker.

In bijlage vind je mijn "probeersel".

Ik ben vertrokken met de tblPersoonsgegevens, tblInstrumenten, tblLidgeld, tblSponsors.
Deze heb ik samengebracht in een frmPersoonsgegevens.


PROBLEEM 1:

Bedoeling:

via frmPersoonsgegevens data van leden, muzikanten, sponsors invoeren via hoofd- en subforms.

Probleem:

Records in frmPersooonsgegevens kunnen met "record verwijder"-knop in formulier gewist worden, maar dit wordt niet gewist in tblPersoonsgegevens, terwijl navigeren en toevoegen en aanpassen wel werkt.



PROBLEEM 2:

Om van alle personen (tblPersoonsgegevens) een tabel te maken met de personen per adres samengevoegd heb ik een query (qryMaaktblVerzendAdressen + Module1) gevonden en toegepast op tblPersoonsgegevens.
Dit werkt zoals het hoort, sorteert alle personen per adres en voegt deze samen in een nieuwe tabel aangevuld met een aanspreektitel (moglijk tot 5 personen).

Deze gegevens kan ik vervolgens via afdruk samenvoegen in een word document plaatsen.
Deze tabel geeft de mogelijkheid om slechts 1 brief te versturen, geadresseerd aan meerdere personen.


Hetzelfde dacht ik te doen voor muzikanten, leden en sponsors apart zodat deze elk apart kunnen aangeschreven worden.

Hiervoor had ik de MaaktblqryLeden, MaaktblqryMuzikanten, MaaktblqrySponsor aangemaakt om daarna de qryMaattblVerzendAdressen aan te passen aan deze tabellen.

Helaas kom ik er niet uit.

Heeft iemand de tijd, moed, energie en vooral zin om mij te redden van bijkomende haaruitval (grijs zijn ze ondertussen al geworden)


P.S. database kan blijkbaar niet geupload worden (1,3 MB) te groot??? Ik krijg telkens de melding dat het om een ongeldig bestand gaat.
 

Bijlagen

Laatst bewerkt:
Voordat je een db upload, moet je hem eerst comprimeren. Daar wordt hij doorgaans al een heel stuk kleiner van. Als je hem daarna zipt, is hij meestal wel te posten. Desnoods, als hij nog boven de 100kb zit, kun je hem met Winrar in meerdere deelbestanden te splitsen. Als laatste redmiddel kun je hem nog op www.mijnbestand.nl o.i.d. zetten. Kunnen we hem ook sponzen.
Probleem 1 wordt vermoedelijk veroorzaakt doordat er gekoppelde records zijn. In welk geval je het persoonsrecord niet gelijk kan verwijderen. Overigens heb ik dan al gelijk het idee dat je formulier niet goed is.
Probleem 2 zou je helemaal niet hoeven te hebben, want waarom zou je een dubbele tabel met dezelfde gegevens maken? Klinkt als nogal onzinnig. Maar voor een definitief oordeel wil ik eerst de db zien :)
 
Probleem 1 in je db: in de tabel [tblInstrumenten] (verkeerde naam volgens mij, want het is geen tabel die instrumenten beschrijft) heb je de velden [Persoonlijk] en [Bruikleen]. Daar heb je selectievakjes voor gemaakt, en dat moet je niet doen. Tenzij ik het helemaal verkeerd begrijp, is een instrument eigendom van de bespeler, of geleend. Beide zou volgens mij niet mogelijk mogen zijn. En dat kan nu wel. Maar daar dus één veld van.
Probleem 2 in dezelfde tabel: het veld [Instrument] bevat een instrumentnaam. Die haal je volgens mij uit de tabel [tblInstrumentnaam], dus dat moet een veld zijn dat het InstrumentnaamID van die tabel opslaat. En geen tekstveld.
Een tabel [tblqryLeden]? Waar is die goed voor? Weg ermee!
Tabel [tblqryMuzikanten]? Idem dito!
En dan tabel [tblVerzendAdressen]. Met een veld [Namen], met daarin de gecombineerde waarden "Lid Een, Muzikant Een, Muzikant Twee". Dat is dus echt een grote NONO in database land...

En dan komen we bij je oorspronkelijke vraag (1, om precies te zijn). Als je de koppelingen tussen de tabellen aanpast, en optie 3 ook selecteert (gerelateerde records trapsgewijs verwijderen) (en ik zou in jouw geval overigens ook optie 2 aanzetten, omdat je een handmatig veld hebt als sleutel) kun je wèl records verwijderen. Ik zou dan overigens ook gewoon de tabel als bron gebruiken, en geen query. Die voegt totaal niks toe namelijk.
 
Hallo Michel,

bedankt voor je steeds snelle reactie.

Als beginneling dacht ik dat ik op goede weg was met de db, maar uiteindelijk lijkt het erop dat ik beter helemaal opnieuw begin.

Ik ben vertrokken van het idee om alle persoonsgegevens van de vereniging in eenzelfde tabel te zetten (muzikanten, leden, sponsors).
De gegevens wanneer iemand een instrument in bruikleen heeft werden opgeslagen in de tblInstrument -> hernoemd naar tblBruikleen.
Omdat sommige leden van de muziekvereniging naast een instrument in bruikleen ook een persoonlijk instrument hebben had ik die selectie mogelijk gemaakt. Doch bij nader inzien is dit inderdaad niet noodzakelijk om in kaart te brengen en zijn slechts de geleende instrumenten van belang.

Naast die gegevens worden ook alle lidgelden opgeslagen in de tblLidgeld en de sponsorgelden in de tblSponsor.

Je zegt van de tblqryLeden en tblqryMuzikanten te liquideren. Ik had deze gemaakt om via "afdruk samenvoegen" de gegevens te kunnen importeren in een Word document.
Wanneer er een brief naar enkel leden dient gestuurd te worden kunnen de samenvoeg velden uit deze tabel gehaald worden, zodat niet alle leden worden aangeschreven, etc.


De bijkomende tnlVerzendAdres, tblVerzendAdresMuzikanten, tblVerzendAdresLeden, tblVerzendAdresSponsor zouden alle gegevens van leden en muzikanten moeten bevatten per uniek adres. D.w.z. dat er maar 1 brief gestuurd wordt naar het adres waar meerdere muzikanten en/of leden verblijven.


Enfin, voor de geroutineerde access-gebruiker zal dit waarschijnlijk "a piece of cake" zijn, maar ik begin zo stilaan door 't bos de bomen niet meer te zien.

Alleszins bedankt voor de moeite en de tijd die je hieraan wil spenderen.

P.S. Als je ergens tijd moest vinden om even schematisch de structuur door te geven van zo'n db ga ik zelf weer voor ettelijke uurtjes aan de slag :confused:
 
De aangepaste naam van de tabel lijkt mij beter, want die geeft nu weer wat de tabel doet. Maakt overigens voor de werking van de db natuurlijk niet uit hoe een tabel heet :)
Als een persoon meerdere instrumenten heeft/bespeelt, dan moet je die per instrument vastleggen. Met je huidige relaties lukt dat verder wel, want op zich zijn die in orde. Dan kun je nog steeds aangeven of een instrument in bruikleen is of niet. Maar zoals gezegd: daar heb je maar één veld voor nodig.
De rest van je problemen kun je prima met queries oplossen, daar hoef je geen tabellen voor te maken. Met queries kun je ook prima samenvoegen in Word. Overigens is het vaak net zo makkelijk om de standaardbrieven in Access te maken, en ze dus vanuit Access af te drukken en te versturen.
 
Is dit een goede indeling van de database?
 

Bijlagen

  • Overzicht DB.jpg
    Overzicht DB.jpg
    88,2 KB · Weergaven: 38
De relatie tussen Instrumentnaam en Uitleen deugt niet. Je hebt gekoppeld op basis van de omschrijving, en dat is geen goede koppeling. Je moet nog een extra veld toevoegen, [InstrumentnaamID], en dat vullen met de ID waarden uit Instrumentnaam.
 
Hallo Michel,

ik ben helemaal opnieuw begonnen met de raad die je gisteren gegeven hebt en tot nu toe gaat alles goed.
Alleen begrijp ik je laatste boodschap niet zo goed.

In tblBruikleen een veld bijmaken InstrumentnaamID (zelfde als in tblInstrumentnaam)? Kan ik dan het veld Instrument in tblBruikleen verwijderen en vervangen?

Dan kan ik geen 1-op-veel relatie afdwingen :o met als gevolg dat ik weer geen records kan verwijderen vanuit het hoofdformulier.

Moet er wel een relatie zijn tussen die tabellen? Het veld instrument in tblBruikleen is een keuzelijst met invoervak die gegevens ophaalt uit tblInstrumentnaam.
 
Laatst bewerkt:
Het is juist wèl de bedoeling om records te kunnen verwijderen. En dat gaat alleen als je op de juiste velden koppelt. Het veld Instrument kan dan inderdaad weg. Ik maak meestal een bijwerkquery om op basis van het veld Instrument de ID waarden aan te vullen.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan