probleem met toevoegquery

[annw]

Ik heb, als acces-leek, met veel geduld en opzoekwerk een database gemaakt, maar ik heb een probleem dat ik niet opgelost krijg.
Ik heb een formulier gemaakt met keuzelijsten met invoervakken die gemaakt zijn op basis van query's. De query geeft het juiste resultaat, het invoervak gebaseerd op deze query geeft het juiste resultaat op het scherm. Wanneer ik echter de vakken via een query selecteer (om er daarna een toevoegquery van te kunnen maken om in mijn tabel wil wegschrijven), zijn deze vakken leeg.

er zijn selectievakken waar het wel bij lukt. bijvoorbeeld de selectie van de persoon, dit vak kan ik gewoon uitlezen via een query
SELECT TBL_kledij_soort.Id_kledij_soort, TBL_kledij_soort.kledij
FROM TBL_kledij_soort
ORDER BY TBL_kledij_soort.Id_kledij_soort;


een ander selectievak geeft als resultaat rare tekens (pijlen, ...) in plaats van de juiste informatie (de query op zich geeft het juiste resultaat, enkel als ik het invoervak dat op basis van deze query gemaakt is wil uitlezen geeft het geen juiste resultaten)
SELECT QRY_kledij_verkoop_soort_maat_stock.Id_kledij_soort, QRY_kledij_verkoop_soort_maat_stock.Stock, QRY_kledij_verkoop_soort_maat_stock.kledij, QRY_kledij_verkoop_soort_maat_stock.Maat, QRY_kledij_verkoop_soort_maat_stock.Id_kledij_soort_maat
FROM QRY_kledij_verkoop_soort_maat_stock
WHERE (((QRY_kledij_verkoop_soort_maat_stock.Id_kledij_soort)=[Forms]![FRM_kledij_verkoop]![txtkledij]) AND ((QRY_kledij_verkoop_soort_maat_stock.Stock)>0 Or (QRY_kledij_verkoop_soort_maat_stock.Stock) Is Null));

een ander selectievak geeft niets als resultaat
SELECT TBL_kledij_prijs.Id_prijs, TBL_kledij_prijs.Prijs, TBL_kledij_prijs.Soort
FROM TBL_kledij_prijs
WHERE (((TBL_kledij_prijs.Soort)=[Forms]![FRM_kledij_verkoop]![txtkledij]));



Kan iemand mij hiermee helpen ?
alvast bedankt!

ann

 

[PFL]

Kun je de database uploaden alsjeblieft?

 

[annw]

upload test.accdb
http://wikisend.com/download/303362/upload test.accdb

kan je hiermee iets doen ?
om het probleem te bekijken open je het formulier FRM_kledij_verkoop, de gegevens invullen en dan de query QRY_kledij_toevoegen uitvoeren, dan zie je het resultaat

Nu ik toch een database upload, ben ik zo vrij om nog een tweede vraagje te stellen. FRM_aanpassen_adrestabel openen, een persoon kiezen, en dan de gegevens aanpassen. om weg te schrijven drukken op Gegevens Opslaan. de bijwerkquery geeft geen foutmeldingen, maar als je in de tabel (TBL_adres) gaat kijken werden er geen aanpassingen gedaan. je kan een volgende persoon kiezen, en dan terug gegevens opslaan doen. als je dan gaat kijken in de TBL_adres, dan zie je dat de eerste aanpassingen zijn doorgevoerd, maar de 2de nog niet. als je dan een derde aanpassing wil doen, krijg je een foutmelding "schrijfconflict - terwij u de record bewerkte, is deze gewijzigd door een andere gebruiker ..." alhoewel de database enkel door mij op 1 pc wordt gebruikt

is het mogelijk om daar ook eens naar te kijken

alvast bedankt !
ann

 

[PFL]

Hallo Ann,

Je hebt een database gemaakt met tabellen die geen enkel verband hebben met elkaar. Dat kan op zich prima (zolang je tenminste geen velden uit verschillende tabellen selecteert in een query...) maar dan kun je net zo goed in Excel werken omdat je database geen relationele database is
Access is bedoeld om relationele databases mee te maken, met relaties tussen de gegevens die je vastlegt in het scherm relaties. Wat jij dus niet hebt gedaan...
Als je mij uitlegt wat je precies wilt doen met je database (want dat is me ook niet helemaal duidelijk) dan wil ik je wel op weg helpen met een voorbeeld database(je).

Maar ondertussen raad ik je aan om een beginnersboek over Access te kopen of een on line beginnerscursus te zoeken. En Microsoft heeft zelf ook een beginnershandleiding op de Office website.

Wat betreft je tweede vraag: in dit geval heb je helemaal geen bijwerkquery nodig. Als jij gegevens wijzigt in een formulier dan wordt de onderliggende tabel automatisch bijgewerkt zodra je het record of het formulier verlaat.
De foutmelding wordt wellicht veroorzaakt doordat je de tabel open hebt staan terwijl je in het formulier bezig bent.

m vr gr,
Paul.

 

[annw]

Hallo,

vermits de database al gedeeltelijk gebruikt wordt (bankafschriften, ledengegevens,...) heb ik enkel de gegevens doorgestuurd die over dit probleem gaan. Niet slim, want zo heb je natuurlijk geen volledig beeld van hoe het in elkaar zit
is er een manier om je de volledige database door te sturen, zonder al die gegevens te grabbel te gooien ?
wat betreft de tweede vraag ga ik direct je goede raad proberen in de praktijk om te zetteb
mvg
ann

 

[PFL]

Dat kan eigenlijk alleen door een kopie van de database te maken en vervolgens gevoelige gegevens te verwijderen of te vervangen door iets onschuldigs.
Als er erg veel gegevens instaan, zou je het merendeel kunnen verwijderen en het restant vervangen door verzonnen gegevens.
Daarna kun je het beste de database 'comprimeren en herstellen' (is een knop onder de tab Database Hulpmiddelen) zodat het aantal MB's aanzienlijk gereduceerd wordt.
Vervolgens in een ZIP-bestand verpakken en uploaden in dit draadje.

 

[annw]

http://wikisend.com/download/188294/upload helpmij.zip
upload helpmij.zip

ik heb de gegevens van de database aangepast

probleem : FRM_kledij_verkoop openen en invullen, daarna QRY _kledij_toevoegen (om later in de TBL_Kledij_verkoop bij te voegen) => prijs en stock blijven 0

Bijwerken ledengegevens : inderdaad, er moest geen bijwerkquery bij.

FRM_uittreksels_leveranciers : beginsaldo en eindsaldo is via subformulieren op dit formulier gezet. zelfde probleem als het eerste probleem : deze vakken zijn leeg als je ze wil uitlezen met een query

goedenavond en bedankt
ann

 

[PFL]

"FRM_kledij_verkoop openen en invullen, daarna QRY _kledij_toevoegen (om later in de TBL_Kledij_verkoop bij te voegen) => prijs en stock blijven 0"

Om met dit eerste probleem te beginnen:

De TBL_Kledij_verkoop staat niet in het scherm met relaties en heeft dus geen enkele koppeling met de andere tabellen. Dus dat graag als eerste doen.

In de QRY _kledij_toevoegen verwijzen de velden naar het formulier FRM_kledij_verkoop i.p.v. de TBL_Kledij_verkoop. Dat is onlogisch want het is nou juist de tabel die je wilt vullen met gegevens

In het FRM_kledij_verkoop staan alleen onafhankelijke velden die weliswaar een rijbron hebben maar geen recordbron. Daardoor is het een niet-gebonden formulier waarmee je geen gegevens kunt wijzigen of toevoegen! Wat je 'invoert' wordt naar het luchtledige weggeschreven!

De oplossing zal waarschijnlijk zijn om (nadat je als eerste de TBL_Kledij_verkoop gekoppeld hebt in de relaties):

A. Een nieuwe query te maken, gebaseerd op de TBL_Kledij_verkoop. Plus eventuele andere tabellen die nodig zijn voor het beoogde doel van de query maar bedenk daarbij wel dat je slechts in 1 van de tabellen die je in de query opneemt gegevens kunt wijzigen of toevoegen.
B. Een nieuw formulier te maken op basis van de nieuwe query.

Ik zei waarschijnlijk omdat ik de database niet zo 1-2-3 volledig kan doorgronden en jij het beste weet hoe hij in elkaar zit

Dat was 1. Ik zal nu naar het tweede probleem kijken....

 

[PFL]

"FRM_uittreksels_leveranciers : beginsaldo en eindsaldo is via subformulieren op dit formulier gezet. zelfde probleem als het eerste probleem : deze vakken zijn leeg als je ze wil uitlezen met een query"

Hier speelt eigenlijk hetzelfde probleem. Het FRM_uittreksels_leveranciers heeft allemaal onafhankelijke velden en geen recordbron.

In de QRY_UITTREKSEL_LEV heb je het veld ID van de TBL_Leverancier gekoppeld aan het veld Wie in de TBL_Uittreksel.
In de relaties is het veld Wie echter gekoppeld aan het veld ID_adres van de TBL_adres!

Wat me verder opvalt aan de QRY_UITTREKSEL_LEV is dat je het veld Waarvoor uit de TBL_Waarvoor opneemt. Volgens mij moet je echter het veld Waarvoor uit de TBL_Uittreksel opnemen omdat je in die tabel gegevens wilt toevoegen of wijzigen. In het formulier dat je baseert op de QRY_UITTREKSEL_LEV wijzig je dan vervolgens dit veld in een Keuzelijst met Invoervak waarvan je de Rijbron baseert op de TBL_Waarvoor. Wat je overigens in het FRM_uittreksels_leveranciers wel gedaan hebt maar zoals eerder gezegd zonder Recordbron....

Overigens kan ik je aanraden om velden die je aan elkaar koppelt in elke tabel dezelfde naam te geven. Is wel zo duidelijk en overzichtelijk.
En ook om autonummeringsvelden niet in elke tabel Id te noemen maar bijvoorbeeld IdWaarvoor, IdUittreksel, IdLeverancier etc.
Ik zou dat nu echter niet meer veranderen in deze database. Access gaat niet altijd even goed om met naamswijzigingen is mijn ervaring.

Ik hoop dat je er zo uitkomt...

 

[PFL]

PS: met Recordbron bedoel ik Besturingselementbron.
Sorry, ik heb een Engelse versie van Access en ik had de verkeerde vertaling in m'n hoofd

 

[annw]

Bedankt voor het antwoord, k ben er nu pas toe gekomen om het uit te proberen. Eerste probleem is opgelost, tweede moet ik nog eens uitzoeken

 

[PFL]

OK, geen dank. En kom gerust terug als je weer vragen hebt.

Ik heb intussen nog eens naar je database gekeken en daarin zie ik erg veel niet-gebonden formulieren, met vaak een knop Opslaan met een 'ingewikkelde' macro erachter. Ik denk eigenlijk dat je te moeilijk doet (en dat bedoel ik zeker niet bot ).

Mijn advies is om nog eens goed naar je tabellen te kijken en te bedenken wat je waar wilt/moet opslaan.

Vervolgens maak je queries op basis van de tabellen waarin je gegevens wilt opslaan. Waarbij je moet bedenken dat je in een query weliswaar velden uit verschillende tabellen kunt selecteren maar dat je slechts in 1 van die tabellen daadwerkelijk gegevens kan wijzigen of toevoegen.

Daarna maak je formulieren die gebaseerd zijn op de queries, d.w.z. gebonden formulieren dus. Dat gaat het makkelijkst met de Wizard Formulier.

Succes!

 

[annw]

ik vrees ook dat het veel te ingewikkeld wordt, maar vermits ik altijd eerst gegevens opvraag via het scherm (jaartal - welke groep / persoon - periode...) die ik daarna in de tabel wil wegschrijven, zie ik niet in hoe ik dit anders kan oplossen ik krijg het meestal wel werkend, maar met veel omwegen ...

 

[PFL]

Vaak heb je aparte tabellen nodig waarvoor de invoer uit de tabellen met de 'basisinformatie' komt.
Als je een voorbeeld kan geven van de informatie die je wilt wegschrijven dan kan ik je wellicht op weg helpen met een uitgewerkt voorbeeld.
Een uitgewerkt formulier bedoel ik...

 

[annw]

2015.09.16 helpmij.accdb
http://wikisend.com/download/388002/2015.09.16 helpmij.accdb

Als jij je wilt verdiepen in mijn database, dan aanvaard ik dit met open armen
een beetje achtergrondinformatie over de opbouw :
1 TBL_Uittreksel en 2 tabellen met data (leveranciers : TBL_Leverancier en dansers TBL_danser) De data wordt in de TBL_uittreksel geschreven via 2 formulieren : FRM_uittreksel_klanten en FRM_uittreksel_leveranciers. 2 formulieren omdat ik geen oplossing vond om in één keuzelijst met invoervak (naam) ofwel de data van de leveranciers ofwel de data van de dansers tevoorschijn te laten komen. dus vertrokken met 1 formulier voor de klantengegevens en 1 formulier voor de leveranciergegevens.

Als ik het goed begrepen heb, zouden deze formulieren op basis van de TBL_uittreksel moeten gemaakt zijn, maar vermits ik veel informatie uit keuzelijsten haal (jaar uit TBL_jaar, naam uit TBL_leverancier of TBL_adres, waarvoor uit TBL_waarvoor, periode uit TBL_periode en saldo uit TBL_uittreksel) krijg ik dit niet in orde. het formulier werkt wel op de manier dat ik het gemaakt heb, via de QRYinvoerenleveranciers en de QRYinvoerenleden.

Nu wil ik het saldo van de rekeninguittreksels opvolgen. daarom heb ik het eindsaldo van het vorige uittreksel via de QRY_uittreksel_eindsaldo opgezocht en dit saldo via een subformulier op het FRM_uittreksel_leverancier gezet. het nieuwe saldo wordt gevormd door bij het eindsaldo het bedrag van deze uitgave bij te tellen (af te trekken) (QRY_uittreksel_eindsaldo2). Dit is ook via een subformulier op het FRM_uittreksel_leverancier gezet. op het scherm is alles ok, probleem is nu om dit weg te schrijven naar de TBL_uittreksel. zoals ik al in de vorige mail zei, zijn deze vakken leeg. het uittrekselnummer wordt ook via een QRY_uittrekselnummer en een subformulier op het formulier gezet, maar dit geeft geen problemen.

zoals je terecht opmerkte is er ook geen relatie tussen de WIE in de TBL-uittreksel en de ID in de tabel leverancier. De 'WIE' verwijst ofwel naar de ID van de TBL_adres (indien het gaat om "K" (klanten) of naar de ID van de TBL_leveranciers (indien het gaat om "L" (leveranciers)) ik kan wel een relatie maken tussen de WIE en de id van de TBL_adres, maar niet met de ID van de TBL_leverancier. vermits dit tot nu toe geen problemen oplevert heb ik me hier ook nog niet veel zorgen om gemaakt

kan je me op basis vand eze informatie verder helpen met het probleem van het begin en eindsaldo ? ik heb op het FRM_uittreksel_leverancier aan 't experimenteren geweest om het niet via een subformulier te doen, maar gewoon een keuzelijst met invoervak, maar voorlopig zonder resultaat.

zoals je kan zien heb ik het probleem met de kledij ook opgelost gekregen, maar niet door het formulier te hermaken op basis van de tabel, vermits ik ook hier met hetzelfde probleem kamp dat er veel gegevens via keuzelijsten met invoervak dienen ingegeven te worden. maar dit werkt

hopelijk is mijn uitleg een beetje duidelijk.
alvast bedankt !

 

[PFL]

Het is me inmiddels denk ik wel duidelijk waar de schoen wringt, zoals we in Nederland zeggen (en wellicht ook in België). Het lijkt erop dat je niet goed weet hoe je gebruik moet maken van de relaties tussen de tabellen, of beter gezegd de koppelingen tussen de gegevens.

Je zegt bijvoorbeeld:
"De 'WIE' verwijst ofwel naar de ID van de TBL_adres (indien het gaat om "K" (klanten) of naar de ID van de TBL_leveranciers (indien het gaat om "L" (leveranciers)) ik kan wel een relatie maken tussen de WIE en de id van de TBL_adres, maar niet met de ID van de TBL_leverancier."

Dit kan dus never nooit. De 'WIE' verwijst ófwel naar de ID van de TBL_adres óf naar de ID van de TBL_leveranciers, maar niet de ene keer naar de ene en de andere keer naar de andere tabel!

Ik zal er vanavond en/of morgen eens induiken. Stap voor stap komen we er wel

 

[PFL]

Hierbij een voorbeeldje van hoe het mijns inziens zou moeten, waarbij ik zo eigenwijs ben geweest (want dat ben ik nou eenmaal ) om bij het begin te beginnen, namelijk de tabel met de gegevens van de leerlingen. In jouw database is dat 'TBL_adres' maar ik vind 'Leerlingen' een logischer naam omdat er meer dan alleen adresgegevens in staan.
De reden dat ik hiermee begin, is dat jij voor mijn gevoel de basisprincipes van Access nog niet helemaal door hebt. En dat zal toch echt eerst moeten voordat we naar meer complexere dingen gaan kijken zoals jouw vragen in je laatste bericht.

In mijn tabel 'Leerlingen' zijn een aantal dingen gewijzigd t.o.v. jouw tabel 'TBL_adres':
- Het veld 'LLNR' heb ik naar voren gehaald (hier kom ik later op terug).
- De velden 'POSTC' en 'GEMEENTE' heb ik verwijderd en ondergebracht in een nieuwe tabel 'Gemeenten'. Daarvoor in de plaats heb ik het nieuwe veld 'GemID' aangemaakt (in de tabel 'Leerlingen') en deze heb ik in het scherm 'Relaties' gekoppeld met het veld 'GemID' van de tabel 'Gemeenten'.
De reden hiervoor is dat je bij voorkeur elk gegeven maar 1 keer opslaat in een database. In jouw tabel komen diverse gemeenten en postcodes meerdere malen voor en dat is niet handig.
Het veld 'Gemeente' en het veld 'Postcode' heb ik beide sleutelveld gemaakt zodat je nooit dezelfde combinatie van gemeentenaam en postcode kunt invoeren. Ook een eigenschap van een goede database: geen dubbele gegevens!
Overigens raad ik je aan om hetzelfde te doen in de tabel 'Leerlingen' door bijvoorbeeld de combinatie Naam, Voornaam en Geboortedatum tot sleutel te benoemen zodat je niet dezelfde leerling dubbel kunt invoeren. (Hoe groot is de kans tenslotte dat 2 leerlingen dezelfde naam hebben én dezelfde geboortedatum?). Dat kan ik nu niet doen omdat veel velden leeg zijn en dat mag niet bij sleutelvelden.
- De velden TEL1, TEL2 en TEL3 heb ik gewijzigd in respectievelijk TelDanser, TelMama en TelPapa omdat je ze zo noemt op je formulieren 'FRM_invoerenLeden' en 'FRM_aanpassen_adrestabel'. Wel zo handig om namen zoveel mogelijk gelijk te houden en bovendien zijn TEL1, TEL2 en TEL3 te vaag.
- Het veld 'Aanpassing_gegevens' vond ik een te lange naam dus daar heb ik 'LaatsteAanp' van gemaakt.

Vervolgens heb ik eerst de query 'GemeentenQry' gemaakt op basis van de tabel 'Gemeenten', waarbij achtereenvolgens de velden 'Gemeente' en 'Postcode' oplopend gesorteerd worden.
Op basis van deze query heb ik toen met de 'Wizard Formulier' het formulier 'Gemeenten' gemaakt, waarbij ik de standaard weergave op 'Gegevensblad' heb gezet.
In dit formulier kun je eenvoudig nieuwe gemeentes en postcodes toevoegen door naar onderen te scrollen of door op het navigatieknopje voor 'nieuw record' te klikken onderaan in het scherm. (De navigatieknopjes worden standaard weergegeven in formulieren tenzij je ze uitzet in de eigenschappen).
Ook kun je bestaande gemeentes en postcodes wijzigen, mochten daar fouten in zitten.
En zoals je ziet, heb je geen 'moeilijk' gedoe nodig met onafhankelijke velden, toevoegqueries en macro's

Daarna heb ik de 'LeerlingenQry' gemaakt, waarin ik alle velden uit de tabel 'Leerlingen' heb opgenomen plus het veld 'Postcode' uit de tabel 'Gemeenten'. De velden 'GemID' en 'Gemeente' van de tabel 'Gemeenten' heb ik dus niet opgenomen en de reden daarvoor zie je later.
Deze query laat ik oplopend sorteren op het veld LLNR.

Vervolgens heb ik op basis van deze query, en wederom m.b.v. de 'Wizard Formulier', het formulier 'Leerlingen' gemaakt waarbij ik de standaard weergave op 'Kolommen' heb gezet (of iets dergelijks; in mijn Engelstalige Access heet het 'Columnar').
Als een formulier gebaseerd is op een query waarin velden uit meer dan 1 tabel zijn opgenomen, vraagt Access ook op basis van welke tabel je gegevens weergegeven moeten worden; in dit geval 'Leerlingen' of 'Gemeenten'. Uiteraard is dat in dit geval 'Leerlingen'.

In het formulier 'Leerlingen' heb ik allereerst het veld 'GemID' gewijzigd in een 'Keuzelijst met Invoervak'. Dat doe je door in de Ontwerpweergave het veld met de rechtermuisknop aan te klikken en vervolgens ga je naar 'Wijzig in' en dan 'Keuzelijst met Invoervak'.
Daarna heb ik bij de eigenschap 'Rijbron' van dit veld de tabel 'Gemeenten' geselecteerd. Vervolgens heb ik op de drie puntjes (...) geklikt achteraan deze eigenschap en een query gemaakt. Kijk zelf maar hoe deze eruit ziet.
Daarna heb ik de eigenschap 'Beperken tot lijst' op 'Ja' gezet en (onder de tab Opmaak) het aantal kolommen op 3, de kolombreedtes op 0, 6 en 1,2 cm en de lijstbreedte op 7,5 cm. (Deze breedtes zijn niet standaard uiteraard maar verschillen per lijst, daar moet je wat mee vogelen).

Als je nu naar de Formulierweergave gaat en je klikt op het pijltje in het veld 'Gemeente' dan zie je een keuzelijst met alle gemeentes en de bijbehorende postcodes, gesorteerd op alfabet. Als je de gemeente van een leerling wijzigt dan zul je zien dat het veld Postcode erboven automatisch meewijzigt. Dat is te danken aan de koppeling tussen de 'GemID' van de tabel 'Gemeenten' en de 'GemID' van de tabel 'Leerlingen'.
Een ander (belangrijk) gevolg van deze koppeling is, dat in de tabel 'Leerlingen' nu nummers staan in het veld 'GemID' i.p.v. de gemeentenamen. Deze nummers corresponderen uiteraard met de GemID's in de tabel 'Gemeenten'.
In het formulier 'Leerlingen' zie je de GemID's niet omdat ik de breedte van de eerste kolom op 0 (nul) heb gezet. Dáár zie je de gemeentenamen, maar in de onderliggende tabel worden dus de GemID's opgeslagen. En dát is nou waar het allemaal om draait in Access!
Die eerste kolom, oftewel het eerste veld van een tabel, is in het algemeen de zogenaamde 'Afhankelijke kolom' (als je je tabellen tenminste een beetje logisch opbouwt). Bij de eigenschappen van de keuzelijst zie je ook de eigenschap 'Afhankelijke kolom', die Access standaard op 1 zet.

Ook in het formulier 'Leerlingen' kun je naar hartelust gegevens wijzigen en toevoegen die zonder allerlei omwegen direct opgeslagen worden in de tabel. Voor het gemak heb ik een knop 'Nieuwe leerling' toegevoegd waar een macro aan vastzit waarmee je naar een nieuw record gaat (afijn, die macro's ken je heel goed ).
Je zou ook nog een knop kunnen toevoegen waarmee je naar het laatste record gaat om te zien wat het laatste LLNR is, zodat je het eerstvolgende nummer kunt bepalen voor een nieuwe leerling. Dat is de reden dat ik de query oplopend gesorteerd heb op LLNR én de reden dat ik dit veld naar voren heb gehaald in de tabel.

Voor het veld 'Postcode' heb ik in het formulier 'Leerlingen' de eigenschap 'Tab stop' op 'Nee' gezet en de eigenschap 'Locked' op 'Ja' (ben even de Nederlandse term kwijt, het is de één na laatste eigenschap op de tab 'Gegevens'. Het is niet de eigenschap 'Ingeschakeld', die moet gewoon op 'Ja' blijven staan!).
Dit heb ik gedaan om wijzigingen, al dan niet per ongeluk, in de postcodes te voorkomen. Postcodes moet je tenslotte wijzigen in het formulier 'Gemeenten'.

Bedenk overigens wel dat je, zoals de tabellen nu opgebouwd zijn, je geen historie bewaart. Als je dus bijvoorbeeld het adres van een leerling wijzigt omdat hij/zij verhuisd is, dan overschrijf je het huidige adres en het oude adres ben je dan kwijt. Dat is niet handig als er bijvoorbeeld facturen zijn gekoppeld aan de leerling!
Als je de historie wilt bewaren, zul je dus een nieuw record aan moeten maken als een leerling verhuist. En op de een of andere manier aan moeten geven dat je het oude record niet meer mag gebruiken, door bijv. het toevoegen van 'OUD' achter de naam. Of door een extra veld in de tabel te maken, bijv. Actief ja/nee.

Er ontbreken trouwens 4 leerlingen in mijn tabel 'Leerlingen' omdat ze in jouw tabel geen woonplaats hebben. Die kon ik niet invoeren omdat in mijn tabel 'GemID' gekoppeld is aan de tabel 'Gemeenten'.

Goed, heel verhaal weer... Ik hoop dat je het allemaal een beetje snapt nou. Zo niet dan weet je me wel weer te vinden

Ik kan je aanraden (en dit zul je waarschijnlijk niet leuk vinden...) om helemaal overnieuw te beginnen met je database. Indien gewenst kun je mijn database als startpunt nemen. De basis van je huidige database is gewoon niet goed en hij zit veel te complex in elkaar. Als je dat probeert te corrigeren zul je op allerlei problemen stuiten, met name bij het koppelen van gegevens. Ik kwam er ook een aantal tegen die ik maar niet vermeld heb.
Bovendien heb je kans dat jouw database niet meer helemaal goed werkt omdat je, naar ik aanneem, al heel vaak problemen hebt gehad en dingen hebt gewijzigd. Daar wordt Access vaak niet zo blij van.

 

[OctaFish]

Er zijn nog wel een paar aanvullende opmerkingen te maken op deze draad met (behoorlijk lange) teksten . Laat ik ook eens wat toevoegen...

1 TBL_Uittreksel en 2 tabellen met data (leveranciers : TBL_Leverancier en dansers TBL_danser) De data wordt in de TBL_uittreksel geschreven via 2 formulieren : FRM_uittreksel_klanten en FRM_uittreksel_leveranciers. 2 formulieren omdat ik geen oplossing vond om in één keuzelijst met invoervak (naam) ofwel de data van de leveranciers ofwel de data van de dansers tevoorschijn te laten komen. dus vertrokken met 1 formulier voor de klantengegevens en 1 formulier voor de leveranciergegevens.

Een klant is hetzelfde als een danser is hetzelfde als een leverancier is hetzelfde als een leerling: doorgaans zijn dat namelijk personen. Personen wonen ergens, hebben dus een adres, hebben een naam of een nummer (of allebei) en meestal ook een email adres en een telefoon. Kortom: entiteiten als personen horen in één tabel thuis. Daarbij geef je dan middels een apart veld aan wat de status is van zo'n persoon. Als iemand meerdere statussen tegelijk kan hebben (een leverancier kan tenslotte ook een leerling zijn) dan gebruik je een veld waarin je meerdere waarden kan opslaan, anders is een veld met unieke waarden genoeg. Dat helpt je gelijk van je probleem met je dubbele formulieren af, want nu is het heel simpel om binnen het formulier te filteren op leverancier, leerling etc.

Daarnaast zie ik in je database allerlei in mijn ogen overbodige tabellen, zoals de tabel Jaar en Dagen. Een jaartal kun je altijd uit een datum herleiden, een dag ook. Iemand schrijft zich in voor een cursus vermoed ik, uit je tabellen op te maken, en die cursussen worden in vaste periodes gegeven. Een startdatum + Periode is dan voldoende om alle cursusgegevens verder te herleiden. Dus gooi alle overbodige tabellen (en velden in de tabellen waarin je ze gebruikt) er uit en minimaliseer het aantal velden dat je nodig hebt. Dat maakt de db al een stuk overzichtelijker. Je hebt volgens mij ook veel te veel queries in gebruik, en dat komt doordat je de formulieren nogal ongelukkig gebruikt. (Ook weer in mijn ogen ). Probeer, zoals PFL ook al aangaf, formulieren zoveel mogelijk op de onderliggende tabellen te baseren (geen queries maken, nergens voor nodig) en gebruik ook subformulieren daar waar dat wenselijk is.

In de tabel [TBL_Naam_Groep] sla je een GroepID en een NaamID op (prima) maar waarom dan ook nog eens de tabel [tblFunctie] met [tblFunctie_Naam] erbij gehaald? Als je de laatste constructie gebruikt, heb je de eerste niet nodig. En omgekeerd. Nu is de tabel dubbel gekoppeld en dat is nergens voor nodig. Kijk daar dus ook nog eens naar; gebruik de juiste koppelingen om te voorkomen dat een tabel ineens niet meer werkt omdat de koppelingen dat tegenhouden.

Ben benieuwd overigens naar je volgende versie; in jouw laatste ontbrak de tabel [tbl_Danser] en ik ben benieuwd wat die moet doen .

 

[PFL]

Bedankt voor de zinnige opmerkingen Octafish! Ik zat zelf ook al te denken aan 1 tabel voor alle personen maar aan de andere kant: van klanten en leveranciers leg je doorgaans niet de voornaam, geboortedatum en het telefoonnummer van papa en mama vast . Maar goed, daar is dan wel weer een mouw aan te passen.

Wat Ann precies voor ogen heeft met die tabel jaren en dagen is mij ook niet geheel duidelijk. Dat was één van mijn volgende vragen aan haar. Als ze tenminste nog niet de moed opgegeven heeft. Ik hoop het niet want dat is helemaal niet nodig.

Eén opmerking van jou begrijp ik niet: hoezo is queries maken nergens voor nodig? Wat doe je dan als je velden uit meerdere tabellen nodig hebt en/of als je bijv. een bepaalde sorteervolgorde of een filter wilt toepassen?

 

[OctaFish]

Een mutatieformulier baseer je op één tabel, dus daar heb je geen query voor nodig. Extra velden die je wilt zien komen dan doorgaans uit keuzelijsten. Maar je mag uiteraard best queries gebruiken. Sorteren/filteren kan perfect op het formulier zelf, dus waarom zou je daar een query voor gebruiken? Bovendien is het bloedje simpel om de default sortering van de query te veranderen, dus het is ook nog eens een hele tijdelijke oplossing.