unieke nummers geven

Status
Niet open voor verdere reacties.
E

Elsverheyen

Gebruiker
Lid geworden
28 jan 2016
Berichten
53
Hallo,
ik heb een database gemaakt van alle graven op een kerkhof en de personen die er begraven zijn.
Elk graf heeft een liggingsnummer gekregen dat bestaat uit 2 delen (nr van plan van kerkhof/ nr per graf op zo'n deelplan).
Per record worden de personen (mogelijkheid om een man en een vrouw in te brengen) genoteerd die in een graf liggen -> zo'n record heeft een autonummering. Maar er kunnen meerdere records per graf zijn.
Nu ben ik alle graven een uniek nummer aan het geven. Dus elk graf heeft maar één nummer. Om de verschillende records per graf gemakkelijk uit te filteren.
Nu wil ik kunnen zien op mijn formulier welk het laatste nummer is dat gebruikt is, om bij toevoeging van nieuwe graven geen dubbel nummer te gebruiken. Het is immers niet zo dat het laatste record ook het laatste nieuw graf is. Als er een bijzetting gebeurd is in een graf zal dat een ander nummer hebben. Het automatisch invullen van dat nummer bij een nieuw graf is niet nodig.
Alleen heb ik geen flauw idee hoe ik dat moet aanpakken.
Al vast bedankt om het eens te bekijken.
Groeten
Els
 
Ik snap eerlijk gezegd je probleem niet:
Elsverheyen zei:
Elk graf heeft een liggingsnummer gekregen dat bestaat uit 2 delen (nr van plan van kerkhof/ nr per graf op zo'n deelplan).
Klik om te vergroten...
Daarmee heb je dan toch al unieke nummers voor de graven? Waarom wil je dan een ander nummer?
 
Hallo,
neen want als er ontgravingen zijn en er komt een nieuw graf boven het ander, dan krijgt dat hetzelfde liggingsnummer maar het oude graf blijft wel in de database zitten. Dus moet er een verschil zijn met het nieuwe graf. Voor mijzelf lukt het met de liggingsnummers en de tekst op het graf (wat ik ook noteer) maar iemand anders gaat mijn database ook gebruiken en dus moet het iets eenvoudiger zijn om die records te filteren.
Groeten
Els
 
Dat regel je dan toch met een volgnummer? Graven zijn volgens mij vaste entiteiten, al kan er dus een laag bijkomen, maar in beginsel hoef je daarna alleen nieuwe namen te koppelen aan het nummer. Het hangt er dus maar vanaf hoe je de db nu hebt ingericht.
Dat zie ik namelijk nog niet helemaal voor me. Normaal gesproken heb je een één-op-veel relatie tussen graf, bezetting en persoon. Een graf kan in de loop der jaren immers aan andere personen gekoppeld zijn.
 
hallo Els,
met het nodige voorbehoud, want misschien zie ik iets over het hoofd ?!?!:
ik veronderstel dat je per record ook de datum van begraving noteert en dan kan je
die datum aflopend sorteren om de laatste begraving terug te vinden
(zowel per grafnummmer als over-all)
mvg,
Duke of Earl
 
Misschien moet ik wat duidelijker zijn :) Ik heb al een veld gemaakt waar ik de nummers ga inbrengen. Dus alle graven gaan een nummer krijgen maar de mensen van de gemeente die mijn database gaan overnemen moeten nadien wel de nieuwe ingebrachte graven verder nummeren. Ze gaan daar waarschijnlijk met 3 mensen aan werken. Dus die persoon die een nieuw graf inbrengt moet kunnen zien welk de laatst gebruikte nummer is of welk het volgend nummer is dat ze moet gebruiken.
Sorry voor de ingewikkelde omschrijving maar als je er mee bezig bent lijkt het simpeler dan moeten uitleggen wat je precies bedoelt en wilt verkrijgen.
Groeten
Els
 
Op zich is het niet zo moeilijk wat je wilt. Ik zit dan aan een Volgnummer functie te denken die automatisch het juiste nummer genereert als je een nieuw graf aanmaakt. Dat maakt je huidige vraag namelijk overbodig. Volgnummers worden ook regelmatig gevraagd in het forum en de code wordt dan ook regelmatig gepost. Ook al omdat je de volgnummers geheel naar eigen inzichten kan samenstellen, en dat dus ook gebeurt.
Met een functie Volgnummer is het ook onmogelijk om een nummer dubbel in te voeren (wat uiteraard al in de tabel is afgevangen).
 
Ik denk dat het lastig gaat zijn met een volgnummer dat maar 1 keer kan voorkomen omdat ik verschillende records heb dat bij 1 graf horen dus moet ik dat nummer meer dan 1 keer kunnen invullen.
Bestaat er soms een formule dat als ik een query maak met 1 van de velden, de gebruikte nummers en die oplopend sorteer, er eentje bijteld en dat ik dat dan in een vakje op mijn formulier kan zetten zodat men daar kan zien wat het volgende te gebruiken nummer is.
Els
 
Jij snapt mij niet, of ik snap jou niet, één van de twee. Hoewel: beide opties kan natuurlijk ook.... Als ik dit lees:
Elsverheyen zei:
moeten nadien wel de nieuwe ingebrachte graven verder nummeren. ... Dus die persoon die een nieuw graf inbrengt moet kunnen zien welk de laatst gebruikte nummer is of welk het volgend nummer is dat ze moet gebruiken.
Klik om te vergroten...
Dan kan ik dat maar op één manier uitleggen (en dat zeg je zelf ook in bericht #1
Elsverheyen zei:
Nu ben ik alle graven een uniek nummer aan het geven. Dus elk graf heeft maar één nummer.
Klik om te vergroten...
Ergo: je moet er dus voor zorgen dat het nummerveld voor de graven een uniek nummer bevat. Dat zeg je namelijk in je citaat. En dat betekent voor mij: een functie die er voor zorgt dat er hoe dan ook een uniek (opvolgend) nummer wordt gegenereerd als je een nieuw graf invoert. Dat kan je handmatig doen (laatste record opzoeken en kijken welk nummer dat staat en ophogen) met de kans op fouten, of automatisch en gegarandeerd foutloos. Ik weet dan wel welke optie ik kies :).
 
Ik denk dat ik de oplossing heb gevonden. Ik heb een keuzelijst gemaakt aan de hand van een query die mijn gegeven nummers aflopend ordent en heb die zo verkleind dat je alleen de laatste nummer kan zien. Kan ik die nu ergens instellen dat hij telkens vernieuwd als er een nieuw nummer is ingegeven en men naar het volgend record gaat?
Sorry voor de vele vragen maar het is al een aantal jaren geleden dat ik de cursus access heb gevolgd en ondertussen niet zoveel aan mijn database heb veranderd.
Al vast bedankt
 
Waarom zo moeilijk terwijl het zó makkelijk is om automatisch het juiste nummer te laten genereren? Dat wil je uiteindelijk toch?
 
hallo Els,
indien een automatische volgnummer-functie voor jou te problematisch zou zijn, kan je misschien deze insteek even bekijken:

(theoretisch) voorbeeld:
op de begraafplaats zijn 3 percelen.
perceel 10 heeft momenteel 60 graven - er is nog plaats voor 30 graven
perceel 20 heeft momenteel 45 graven - er is nog plaats voor 30 graven
perceel 30 heeft momenteel 80 graven - er is geen plaats meer voor nieuwe graven

voer alle liggingsnummers in voor ieder perceel (zowel de reeds bestaande als de mogelijks toekomstige graven), dus

90 liggingsnummers voor perceel 10 genummerd van 10-001 tot 10-090 (60 bestaande en 30 mogelijks nog te graven)
75 liggingsnummers voor perceel 20 genummerd van 20-001 tot 20-075 (45 bestaande en 30 mogelijks nog te graven)
80 liggingsnummers voor perceel 30 genummerd van 30-001 tot 30-080 (80 bestaande en 0 mogelijks nog te graven)

in de tabel van de liggingsnummers zet je een extra Ja/Nee veld om te zien of het liggingsnummer wel of niet gebruikt kan/mag worden
bij de invoer van een begrafenis kan je dan eenvoudig vermijden dat een "ongeldig" liggingsnummer gebruikt wordt.

uiteraard blijft een automatische nummer-functie een betere oplossing, maar misschien is bovenstaande omweg/noodoplossing wel een
mogelijkheid??? Indien niet: forget what I just said :cool:
 
Het is allemaal niet zo makkelijk als ik gedacht had. Wat ik nu heb denk ik is het makkelijkste. In u voorbeeld moet men vooraf weten hoeveel graven er op een bepaalde plaats nog gaan bijkomen en dat is vooraf niet altijd duidelijk. Voor mezelf zijn die unieke nummers per graf niet nodig omdat ik per graf het opschrift noteer met wie er allemaal ligt begraven en dat in een kader op mijn formulier staat, maar de updates doe ik 1x per jaar. De mensen van de gemeente gaan dat niet verder zetten dus laat ik dat vak omdat het toch niet meer gaat bijgewerkt worden. Zij kunnen dus niet zien of er meerdere records (personen) bij 1 graf horen. Ik heb mijn database leeg gemaakt en er enkele voorbeelden in gezet misschien is het dan duidelijker. Na mijn update wordt alles op de website aangevuld waar de mensen het kerkhof kunnen raadplegen. Hier kan je zien hoe uitgebreid het al is. Ik heb 2018 records voor een 1800-tal graven. http://www.erfgoedcelkapelleopdenbos.be/Kerkhof/Kapelle/kerkhofKap.php
Omdat het gecomprimeerde bestand te groot is heb ik het in mijn dropbox gezet zie volgende link
https://www.dropbox.com/s/iuy7a223s35djk4/K_O_D_B_kerkhof test vraag.mdb?dl=0
Bedankt om alvast een keer te kijken
Els
 
Vergeet het voorbeeld van Duke, want dat snap ik óók niet.... En zo zou ik het dus absoluut niet doen. Ik zal in je voorbeeldje een functie zetten die al je problemen (hopelijk) oplost :).
 
Gelijk al wel een paar opmerkingen:
1. Ik heb de indruk dat je tabellen slecht genormaliseerd zijn, gezien de tabellen [tbl_wed/echgte4], [tbl_wed/echgte6] etc. Dat zijn zo te zien allemaal dezelfde tabellen met andere namen. Daar zou ik, als dat nog kan, zeker één tabel van maken met een extra veld waarin je het soort graf (ik vermoed dat dat het onderscheidende element is) aangeeft. Dit is vragen om moeilijkheden!
2. Datzelfde geldt voor queries als [(+)pl_man] en [(+)pl_vr]. Die werken op een niet-genormaliseerde tabel. Je zou met één query kunnen volstaan die je op een formulier filter.
3. Wat die tabel ([genealogische_en_grafgegevens]) betreft: veldgroepen als [weduwnaar/echtgenoot1] en `[echtgenote/weduwe2] geven al aan dat hier aparte (gekoppelde) tabellen van gemaakt zouden moeten worden.

Dat gezien hebbende, hoop ik dat de 'normale' oplossing wel mogelijk is, want daar begin ik nu aan te twijfelen :).
 
Hey,
die tabellen wed/echtg 3 en 5 (mannen) en tabellen wed/echtge 4 en 6 (vrouwen) zijn de personen uit een 2de en 3de huwelijk die horen bij de personen uit de hoofdtabel. Zij kunnen niet in 1 tabel want dan weet ik niet meer wie bij wie hoort. Ze liggen ook niet allemaal op het kerkhof begraven. Het zijn vooral genealogische gegevens voor mensen die opzoekingen doen naar andere familieleden.
Mijn kennis van access is ook niet super groot en ik heb mijn plan getrokken met wat ik in mijn cursus vond en omdat dat vooral over firma's en artikels en dergelijke gaat is het moeilijk om dat te vertalen naar het soort database dat ik heb. Ik heb ook in de loop van de jaren een aantal velden die toch niet zo relevant waren verwijderd en andere bijgemaakt. Nu de laatste maand heb ik voor de gemeente veel nieuwe dingen toegevoegd zoals al die vormen van begraven, termijn van begraven en de contactpersoon. Daar heb ik redelijk moeten op zoeken om dat juist in die brief te krijgen. Ik weet zelfs niet of het de gemakkelijkste oplossing was :)
Nu de persoon die mijn gegevens omzet naar de website krijgt van mij een exceltabel met alleen de records waar iets aan veranderd is, dus als ik daar te veel aparte tabellen heb zou dat wel eens in de soep kunnen draaien.
Maar toch bedankt voor de opmerkingen
Els
 
Hoi Els,
Je geeft in je eerste regels zelf al min of meer aan waarom ik gelijk heb, en jij niet. Je hebt het namelijk steeds (terecht overigens) over 'personen'. Daarmee definieer je het object 'mens' dus als identiek. En identieke entiteiten sla je (bijna) altijd op in één tabel. Of ze nu levend zijn of niet, maakt niet uit. Ook niet of ze elders wonen of op de begraafplaats liggen. Ze kunnen (nee: in mijn ogen zelfs moeten) in één tabel.
Ik snap ook wel dat je de db hebt gemaakt in een tijd dat je minder van Access af wist, maar dat mag geen reden zijn om versie 2 van de database dan maar minder goed in elkaar te zetten. Ik denk dat veel van je problemen juist worden veroorzaakt doordat de db niet goed is genormaliseerd. En dat je die problemen dus kunt oplossen door de db wél te normaliseren! Ik wil volgende week wel eens informeren bij de begraafplaats op het werk hoe zij de gegevens organiseren. (Ja, mijn baas heeft eigen begraafplaatsen :) ).
 
Octafish,
ik zie het niet denk ik, omdat je zelf in een vorig bericht zet: Wat die tabel ([genealogische_en_grafgegevens]) betreft: veldgroepen als [weduwnaar/echtgenoot1] en `[echtgenote/weduwe2] geven al aan dat hier aparte (gekoppelde) tabellen van gemaakt zouden moeten worden. Dus wat is het verschil? En als te veel ga vranderen ga ik dan weer niet van die lastige berichten krijgen?
Els
 
Onderlinge relaties zoals huwelijken en kinderen kun je op een aantal manieren vastleggen. De mooiste manier vind ik zelf om alle personen in één tabel te houden. Daarbij heb je dan een verwijsveld nodig op het moment dat er een relatie is met een andere persoon. Zo kun je een persoon A opnemen die getrouwd is met Persoon B. Beide personen neem je op in de personentabel. Probleem daarbij is dat personen verbanden aangaan, zoals huwelijken. En wel eens scheiden, en dan een (doorgaans) andere persoon vinden. Persoon C kun je dan ook opnemen in je tabel, maar als je één partnerveld hebt, heb je een probleem, want bij persoon A moet je dan de parter aanpassen van B naar C. En als je dat doet, ben je de historie kwijt want in de db zie je dan nooit meer dat A ooit met B getrouwd is geweest.
Daarom zou je dus een aparte tabel moeten hebben waarin je alle relaties opneemt. Dus elke keer als persoon A een nieuwe relatie vastlegt, maak je in die gekoppelde tabel een record aan. En dat is de constructie die ik bedoelde: één tabel waarin je de relaties vastlegt tussen de personen die in de hoofdtabel staan. Dan heb je dus geen velden als [echtgenoot 1] en [echtgenoot 2] etc. meer nodig, want elke relatie leg je apart vast. En persoon A kan dan één relatie hebben, of 20: maakt allemaal niet meer uit, want je kunt alles vastleggen. Bij jou is dat niet mogelijk.

Ik zei weliswaar 'gekoppelde tabellen' in bericht 4, maar in het onderhavige voorbeeld gaat het uiteraard maar om één tabel. De meervoudsvorm was omdat de constructie op meer plaatsen gemaakt kan worden, wat dus meerdere gekoppelde tabellen oplevert. Maar elke tabel bevat maar één entiteit. In essentie moet je een db zo zien: alle entiteiten (groepen objecten) die hetzelfde beschrijven, zoals personen, relaties en graven, zet je in één tabel. Verbanden tussen die tabellen leg je in koppeltabellen.
 
OctaFish,
in mijn 2 cursussen was nog geen sprake van gekoppelde tabellen. Ik heb het opgezocht maar dan wordt het precies wel neig ingewikkeld. Ik kan de gegevens alleen laten invullen door een formulier en niet door gegevens rechtstreeks in de tabellen te laten invullen. En blijkbaar is dat precies nog niet zo simpel omdat in een formulier in te bouwen?
Els
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan