acces duplicaten

Beste acces experts,

Ik heb een database gemaakt in acces. Nu wil ik graag voornaam, achternaam, mailadres en geboortedatum koppelen. Het is nu zo dat ik twee dezelfde personen kan invoeren, zelfde voor-en achternaam mailadres etc. als ik alleen de voornaam indexeer en "geen duplicaten" activeer kan ik geen twee dezelfde voornamen meer invoeren.......niet handig. Ik zou graag willen dat de combinatie voor-achternaam, mailadres en geboortedatum uniek zijn. Hoe kan ik dat het beste indexeren?. Voor de duidelijkheid deze NAW gegevens staan in 1 tabel.

Alvast bedankt voor het meedenken

Medical

Van een persoon zijn maar een paar gegevens uniek, waarvan het BSN natuurlijk het bekendste is. Maar dat mag je niet altijd opslaan (nu al helemaal niet met de nieuwe AVG). Als je wilt voorkomen dat je personen dubbel invoert, dan moet je dus naar andere oplossingen gaat zoeken. Bij voorkeur naar een gegeven dat uniek is. Als je géén personen opslaat zonder email adres, dan is dat veld op zichzelf al genoeg, want het email adres is per definitie uniek; niemand in de wereld heeft eenzelfde email adres als jij. Waarom dan meer velden in de index zetten?

Is het veld email niet verplicht, en ook niet altijd ingevuld (dat kan uiteraard altijd, vooral bij oudere personen) dan heeft het email adres niet zoveel te zoeken in een index. Bij het samenstellen van een (unieke) index, ga je altijd voor het minimale aantal velden dat nodig is om de index samen te stellen. Voornaam en Achternaam moet dan in de meeste gevallen al kunnen volstaan als het om een kleinere database gaat, geboortedatum + adres is vaak ook een goede.

Voorkomen dat iemand een persoon dubbel invoert, kun je echter nooit, want je hoeft maar één letter in de velden te veranderen (een typefout in de achternaam) en je ‘unieke’ waarde is al om zeep. Hoe meer velden in de index, hoe groter de kans op die fout. Ik vind een beroep op de ‘common sekse’ van de gebruiker dus veel zinvoller.

Bijvoorbeeld door eerst twee velden te vragen (die voor de index zijn prima) middels een ‘voorzetformulier’ waarmee je in de database controleert of die persoon al bestaat. (In een keuzelijst laten zien). De gebruiker kan dan twee dingen doen: toch een nieuwe persoon opvoeren (hij/zij weet zeker dat de persoon nieuw is), of de bestaande persoon (of wellicht voldoen er meer en staan er dus meer namen in de keuzelijst) openen.

Overigens (en dat is het antwoord op je vraag) kun je makkelijk in het indexvenster een unieke index maken op basis van meerdere velden. Je begint met het eerste veld, geeft die een Indexnaam, en zet vervolgens de andere velden er onder. Samen vormen de velden dan de index.

Beste OctaFish,

Bedankt voor je duidelijke uitleg, ik ga hiermee bezig en denk dat een uniek mail adres misschien wel de beste oplossing zal zijn. Ik zit alleen als een echtpaar hetzelfde mailadres hebben (wat veel voorkomt) dat het dan niet werkt. ik ga uitzoeken of ik toch ergens een unieke waarde kan invullen bij de cursisten.

Ik heb ook nog een andere vraag; ik ben zo brutaal om het maar in de groep te gooien. Ik heb 3 selectievakjes, 2 in het formulier en 1 in het subformulier. Er zou altijd maar 1 van deze 3 aangevinkt mogen zijn. zou je me hier ook mee kunnen helpen?.

Alvast bedankt

Medical

Een email adres is weliswaar uniek, maar als de gebruikers dat niet zijn, dan heb je alsnog wellicht een probleem. Maar nogmaals: ik zou mij daar niet druk om maken, en een goede check inbouwen op dubbele namen/records, en het dus aan de gebruiker overlaten om de juiste beslissing (nieuwe/bestaande klant) te nemen. Je voorkomt fouten tóch niet.
Die constructie met de selectievakjes snap ik niet; een subformulier zou gegevens moeten bevatten die weliswaar gerelateerd zijn aan het hoofdformulier (cursist vermoed ik) maar een afhankelijkheid zoals jij hem beschrijft kan ik mij dus niet voorstellen. Ook niet wat je dan zou willen afdwingen.

Beste OctoFish,

Ik zal het proberen beter uit te leggen.

Ik heb ik het hoofdformulier twee selectievakjes 1-nog geen cursus gedaan en 2-aangemeld voor cursus (dit is gemakkelijker te zoeken in query's. In het subformulier in de vorm een tabel komen alle opleidingen die de cursist heeft gedaan. Achter elke regel (cursus) kan ik het vakje betaald aanvinken ik kan zo ook gemakkelijk vinden wie wel of niet heeft betaald. Ik heb een printscreen gemaakt voor de verduidelijking. Ik hoop het zo duidelijker te hebben uitgelegd.





Vriendelijke groet,

Medical

Je uitleg is prima, je opzet niet. Beide vinkjes op je hoofdformulier zijn overbodig, want herleidbaar uit je subformulier. Het simpele feit dat het überhaupt mogelijk is om het vinkje bij [Nog geen cursus gedaan] aan te vinken, terwijl er in het subformulier 20 cursussen kunnen staan is volslagen ondenkbaar in een goede database. Nog geen cursus gedaan? Dan heb je geen records in het subformulier. Simpeler dan dat is het niet. Aangemeld voor cursus? Idem dito. In het hoofdformulier beide vinkjes aangezet? Is dat niet in tegenstrijd met elkaar? Of wil je onderscheid tussen de situatie dat iemand voor een cursus is aangemeld die nog moet komen (de eerste cursus dan uiteraard) zodat dan beide vinkjes aan moeten staan, en zodra de cursus gestart is, dat dan het tweede vinkje uit moet? Allemaal herleidbaar!

Medical zei:

(dit is gemakkelijker te zoeken in query's)

Klik om te vergroten...

Deze opmerking baart mij ook lichte zorgen, want dit soort 'gemak' mag nooit een reden zijn om extra, en vooral nutteloze, velden in een tabel te zetten. 'Gemakzucht' is vaak een teken van onkunde, als het om databases gaat. En je maakt het jezelf dus veel moeilijker dan noodzakelijk, want je moet nu ineens allerlei dingen gaan programmeren om te voorkomen dat gebruikers 'onmogelijke' combinaties invullen. Kortom: niet doen! Vinkjes weghalen, en de gegevens distilleren uit de beschikbare gegevens. En dat is best simpel; zo kun je met een Outer Join in een query heel makkelijk zien wie er nog nooit een cursus heeft gehad, en wie wel. Met diezelfde query kun je óók nog eens zien wie wel is ingeschreven op een cursus die nog moet plaatsvinden (startdatum > huidige datum). En zo kan ik nog wel even doorgaan.

Het vakje [Betaald] is uiteraard prima. Al kan je daar ook een datumveld voor gebruiken, wat in essentie hetzelfde doet, maar je meer informatie geeft (slechte betalers bijvoorbeeld). En het laatste 'kritiek'puntje: je zult in een database van mij nooit een ingesloten bijlageveld aantreffen. Vervang dat door een tekstveld met een verwijzing naar het bestand op een harde (netwerk)schijf.

Beste OctoFish dit zijn nogal wat dingetjes. Zoals je hebt gemerkt ben niet super bedreven in acces ik heb dit ook met de beste bedoelingen gedaan. Ik kan hier zeker iets mee. Ik ga eerst een week op vakantie en daarna pak ik het weer op. Bedankt voor je feedback en tot later.

Groeten,
Medical

Medical zei:

ik heb dit ook met de beste bedoelingen gedaan.

Klik om te vergroten...

Daar twijfelt denk ik niemand aan . Beste bedoelingen zijn echter doorgaans niet genoeg om een goede database te bouwen. Dat kan alleen met voldoende inzicht in de werking van databases. Wat dat betreft ben je op de goede weg, door je vraag hier neer te leggen .
Fijne vakantie dus, en we pakken het weer op als je terug bent!

Goedemorgen daar ben ik weer. Ik heb de beide vinkjes in het hoofd formulier verwijderd, nu probeer ik de personen te vinden die nog niet aangemeld zijn voor een cursus. Ik vul bij een query onder "cursus" IsNull in zodat ik de mensen krijg waar nog geen cursus is ingevuld. Helaas komen niet alle personen naar voren, van de 13 komen er maar 2 tevoorschijn.....

Als je dat zelfde op het formulier met de R-muis op het cursus veld ook doet en kies bij criteria voor het zoeken ook naar "IsNull " ?
Zorg wel dat al je overige zoekacties uit staan, er mag geen ander filter aanstaan.
Onderin het formulier hoor je te kunnen zien of al je records zichtbaar zijn, bij het navigatie deel helemaal onderaan.
Op jouw plaatje staat daar niets omdat je die gemaakt hebt met een lege database?

Vind je ze op deze manier alle 13 dan lijkt het op een fout in de query?

Het is dus een pure controle methode.

Super het werkt! maar nu het volgende. Als ik in het hoofdformulier NAW gegevens invul en ik doe niets aan het subformulier, omdat we iemand alvast wel willen registreren maar deze persoon zich nog niet voor een cursus heeft opgegeven, komt hij niet tevoorschijn in de query "nog geen cursus gedaan". Als ik in dat subformulier de cursus BLS invul en druk op opslaan en daarna dit weer verwijder en weer op opslaan druk komt hij wel zichtbaar in de query. Het is net of het subformulier eerst "geactiveerd" moet worden.

Medical zei:

et is net of het subformulier eerst "geactiveerd" moet worden.

Klik om te vergroten...

Bijna goed . Als je een formulier opent, dan zie je de actuele status in dat (sub)formulier. Als er iets wijzigt in het hoofdformulier, dan ‘ziet’ het subformulier dat niet automatisch, omdat je naar de (in het subformulier) ongewijzigde gegevens kijkt. Het subformulier is namelijk niet gewijzigd. Je moet daar dus een Requery op geven.
Mooi dat je het antwoord van route99 snapte, want dat ging mij boven de pet .

Ik heb het wel een aantal keren moeten lezen hoor......maar het is goed gekomen. Ik ga eerst even bestuderen hoe ik die requery aan de loop krijg. Bedankt voor je snelle reactie

Senso sinds wanneer draagt die bij in dit topic... :shocked:
Ik heb het wel een aantal keren moeten lezen hoor... maar vond niks...
Misschien heeft ie zijn antwoord weggehaald? Kan zijn... ben net weer terug...

Vanmorgen geen tijd om een plaatje te maken, maar heb er een van een super simpel formulier... hoe je een zoekcriterium gebruikt op een veld op een formulier met een veldnaam "supervisor".
Bij het toepassen van de R-muis op het veld kun je kiezen hoe je het wilt doen.
Als ik ergens nog geen query van geschreven heb dan doe ik dat zo...
Als je meerdere velden op het formulier hebt staan kun je dat bij het extra veld of velden naar keuze nog vaker toepassen.
Je kunt in principe dus op elke (zinvolle) veld combi gaan zoeken volgens het ingevuld criterium, wat je anders via een query zou kunnen doen.
Dat vind ik zelf erg handig als ik eens een keer wat moet zoeken in een of meerdere velden waar ik niet zo vaak in zoek (maar die keer wel omdat er blijkbaar iets bijzonders gezocht wordt...).

Verkeerde persoon voor ogen, route99. Ken gebeuren . Op een formulier kun je op dezelfde manier zoeken/filteren als in een tabel/query, dus voor simpele zaken is dat prima. Wil je uitgebreider zoeken, dan is een formulier met speciale zoekfuncties aan te raden. Al was het maar omdat dat in de praktijk (en daar gaat het uiteindelijk toch om) vele malen sneller werkt dan filteren per veld. Hoe meer velden, hoe meer tijd dat immers kost.

Maar ik hou niemand tegen die via de ingebouwde zoekmethodes wil zoeken, die zitten er immers niet voor niks .

Ken gebeuren...

Ik prees het vooral aan als speciale optie en om heel snel te checken of je query wel klopt en de TS had een probleem juist daarmee en dan is het erg handig als je een methode kent om het op een andere manier te verifiëren.
Dat laatst lijkt me erg belangrijk bij databases en dat was de vraag van de TS. Het was geen claim op de beste opzoek methode...
Denk dat veel mensen niet eens weten dat het zo kan en soms heel krachtig kan zijn voor niet reguliere searches of om een bestaande search die vreemde resultaten geeft op een andere manier te checken.

...die via de ingebouwde zoekmethodes wil zoeken, die zitten er immers niet voor niks

Klik om te vergroten...

Juist en daar ging het hier om en was in dit geval dus zeer correct & efficient. Em ik vermoed dat de TS bij zo een vraag hier juist op zat te wachten en hij heeft het zelfs zonder het plaatje voor elkaar gekregen :thumb:

Beste experts, stop de persen! Ik ben maar een amateur.....niet zo snel. Ik ben nog bezig om uit te vogelen hoe het met de requery werkt. Ik kom erop terug...

Nu heb ik de code (Me.Cursus_particulieren.requery) ingevuld bij het hoofdformulier en het subformulier maar er gebeurt niets, tenminste niet wat ik wil. Is dit wel de goede code ?

Stuur weer eens een nieuwe db mee, dat kijkt wat makkelijker.

Ik heb een lege (complete) database die wilde ik meesturen maar dat lukte helaas niet. Ik hoop dat je hier voldoende aan hebt.