Verplaatsen van gegevens

Nu h.e.a. goed werkt wil ik graag een mogelijkheid om de inhoud van geselecteerde records te verplaatsen naar een nu nog lege database.
beide database hebben dezelfde structuur, er zit wel een verschil in wat persoonsnummer betreft in de eerste (gevulde ) database kan er geen duplicaat van zijn, terwijl dat in de tweede juist wel moet kunnen.
kan dat met een Query?

Tuurlijk kan dat met een query. Ik vraag me af waarom je dat zou doen, maar daar gaat het hier natuurlijk niet om. En waarom je duplicaten zou toestaan in een tabel die een kopie is van een tabel waarin dat níet mag, vind ik ook een beetje wonderlijk. Dat riekt naar een niet optimaal genormaliseerde database. Maar zoals gezegd: dat is hier niet de vraag . Het makkelijkste antwoord heb je al (Ja). De uitwerking is heel simpel: koppel de tweede database aan de eerste, en vul hem met de records die je wilt archiveren (ik neem aan dat dat je bedoeling is). Verwijder vervolgens die records in je hoofd database. Dat kun je dan nog voor het gemak in één procedure met één knop afvangen.

Als het slechts om een eenmalige actie gaat:
Zorg dat er geen sleuteltje staat bij het persoonsnummer (geen sleutelveld dus), in je tweede database.
Vervolgens alles selecteren, kopiëren en plakken.

Frandor zei:

er zit wel een verschil in wat persoonsnummer betreft in de eerste (gevulde ) database kan er geen duplicaat van zijn, terwijl dat in de tweede juist wel moet kunnen.

Klik om te vergroten...

@luc: dit geeft al aan dat het géén eenmalige actie is, want in dat geval zou er maar één exemplaar van de unieke nummers in de nieuwe tabel voorkomen (is immers uniek in de eerste tabel) en dan mag dat veld dus nog steeds een sleutelveld zijn .

We weten eigenlijk niet genoeg van wat de bedoeling is.
Maar stel nu dat Frandor 2 tabellen heeft: de ene met klanten; de andere met leveranciers. Wanneer hij die wil samenvoegen heeft hij uiteraard onmiddellijk dubbele contactnummers.
Maar hij zou kunnen besluiten om er een tweede sleutelveld aan toe te voegen met daarin de aanduiding of het om een klant of een leverancier gaat.
In dat geval is het natuurlijk noodzakelijk om tijdelijk de sleutelvelden uit te schakelen, en achteraf terug toe te voegen. En dan zou het ook om slechts een eenmalige actie gaan.

LucHeyndrickx zei:

We weten eigenlijk niet genoeg van wat de bedoeling is.

Klik om te vergroten...

Klopt. Ik wacht nog steeds op de dag dat een vragensteller in één keer een duidelijke (Access)vraag stelt .

LucHeyndrickx zei:

Maar stel nu dat Frandor 2 tabellen heeft: de ene met klanten; de andere met leveranciers. Wanneer hij die wil samenvoegen heeft hij uiteraard onmiddellijk dubbele contactnummers.

Klik om te vergroten...

Dat zou bijzonder slecht zijn, want een klant mag natuurlijk nooit hetzelfde nummer als een leverancier hebben, of omgekeerd. Ook al gebruik je daarvoor aparte tabellen. Dan kun je, als je dat al zou willen, de aanduiding ook veel beter in het nummer opnemen. In één veld dus.

Verder zou het wel héél erg leuk zijn, als TS ook nog een keer reageert . Wat mij betreft wachten we daar dus op, voordat we verder gaan speculeren. Zonder van de (in ieder geval mijn) tijd :d.

Beetje laat met mijn reactie, maar ik kon niet eerder.

De database heeft niets met klanten/ leveranciers van doen.
Gaat puur op de gegevens van de ene naar de andere te verplaatsen.
Gaat om een begraafplaats waarbij de gegevens en foto van de geruimde graven bewaard moeten blijven.

Hopelijk is dit wat duidelijker.

Dus geen eenmalige actie . De vraag terug is: kon je wat met mijn antwoord (#2)? Want daar is nog geen reactie op.

En waarom zou je dan niet gewoon je oorspronkelijke tabel laten staan. Maar hier dan ook een tweede sleutelveld aan toevoegen met daarin bijvoorbeeld het jaartal waarop het graf gemaakt is?
Jaartal van het verdwijnen van het graf is geen goed idee, vermits je dat wellicht nog niet weet, en een sleutelveld mag niet leeg zijn.

Het kan zijn dat ik wat over het hoofd zie,
Sleutelveld is autonummering.
het veld nr. en graf nr. zijn belangrijk in de lege db mogen en kunnen er dus duplicaten in komen t.z.t.
Dit is n beetje vaag, komt doordat de gemeente wel de grafstenen ruimt maar nog niet de graven, tot er iemand daar begraven wilt worden.
Het aantal dat er daadwerkelijk geruimd is is klein, tenminste tot nu toe, kan ook zo zijn dat men besluit om al de graven zonder steen in een keer te ruimen.

Het is an sich geen slecht idee om de oude geruimde graven naar een historie tabel te verplaatsen, ook al vindt Luc dat een slecht idee. Ik heb zelf ook een tijdje de applicatie beheerd waarmee in Amsterdam de Nieuwe Ooster wordt beheerd, en ik snap dus wel een beetje hoe de materie in elkaar zit. En dat houdt voor de dagelijkse praktijk in dat je de fysieke graven altijd up-to-date wilt houden, zonder dat je de historie verliest. En dan is het dus een goed idee om de oudere gegevens, die dus geen betrekking meer hebben op de huidige indeling, te verplaatsen naar een nieuwe database/tabel. Zodat je ze nog steeds kan raadplegen, maar ze de bedrijfsvoering niet in de weg zitten.
Dat je in die tweede database/tabel een nieuwe autonummering gebruikt is dan ook geen enkel probleem; die nummering is alleen bedoeld om de records makkelijk terug te vinden (sleutelveld dus). Ik zie geen probleem om je plan door te zetten .

Jouw voorstel van 2 toepassen?
Misschien is mijn redenatie niet goed, Ooit in het Dbase 4 verleden zoiets bij de hand gehad voor een vereniging waarbij het rugnummer bleef maar de personen van tabel veranderden. gemerkte records kopieeren naar oud leden en daarna de records verwijderen uit het huidige bestand.

Ik snap je laatste bericht niet. Leg eens uit wat je precies wilt verplaatsen. Je gaf zelf aan dat in je brontabel je unieke waarden hebt die je wilt verplaatsen naar een tabel met dezelfde structuur, maar waarin diezelfde waarde niet meer uniek mag zijn. Vervolgens haal je een voorbeeldje aan waarin je personen wilt verplaatsen. De ID van een persoon is per definitie altijd uniek (BSN bijvoorbeeld), dus hoe vaak je een persoon ook verplaatst naar een andere tabel, daar zal nooit een duplicaat op zijn. Dat nummer wordt eenmalig uitgegeven, en daarna niet meer. Dus in je BU tabel is het BSN nog steeds uniek, ook al maak je dat veld niet uniek. Mag natuurlijk, maar het zal geen wezenlijk verschil maken of BSN uniek is of niet. Iets vergelijkbaars zul je hebben met de tabel met de fysieke grafplaatsen: ook die zijn bij jullie uniek, en blijven dat dus óók als je ze verwijdert uit de tabel. Je kunt een graf dichtgooien/verwijderen en er een theehuisje op zetten; dan heb je dat graf niet meer nodig en kan hij weg uit de tabel. Bijvoorbeeld. Overigens zou ik in dat soort gevallen met een selectievakje Actief/Niet actief werken, want het gaat dan toch om vrij kleine hoeveelheden records.

Grafbezetting is natuurlijk wél iets om te backuppen, want een geruimd graf is fysiek nog steeds aanwezig en kan weer opnieuw gebruikt worden. Dan heb je nog steeds hetzelfde graf, maar met andere 'bewoners'. De oude records kun je dan terugvinden in de BU tabel. Dus je hebt in je hoofdtabel een tabel Bezetting, met daarin het Veldnummer en Grafnummer (als de grafnummers uniek zijn, is grafnummer genoeg). En daarnaast dus de nummers en overige gegevens van de personen die er begraven liggen. Als het graf geruimd wordt, al dan niet volledig, dan verplaats je die gegevens naar je BU tabel. En verwijder je eventueel dus het record uit de hoofdtabel, zodat je het graf weer opnieuw kan uitgeven.

Overigens was het bij ons zo dat er in één graf meerdere bijzettingen konden zijn, en dan heb je dus sowieso geen uniek grafnummer. Dat is pas uniek in combinatie met het laagnummer. Dus een graf met 4 lagen heeft dan 4 unieke nummers: Graf1+Laag1, Graf1+Laag2 etc. Als ik dit voorbeeld er even bij houd, en ik zou dit graf ruimen, dan komen er in de BU tabel dus óók 4 records bij. En als over 25 jaar hetzelfde graf wederom wordt geruimd, dan kunnen dezelfde 4 records (met uiteraard andere persoonsgegevens) nóg een keer worden toegevoegd aan de BU tabel. Moet dus allemaal kunnen zonder problemen.

Ben benieuwd hoever ik er naast zit .

Bij persoon bedoelde ik de gegevens van die person(en).

Het stukje over grafbezetting komt helemaal overeen, er zijn een aantal grafvelden met nr. veld 1 bv waarbij de grafnummering ook met 1 begint, vandaar die twee unieke velden.
Grotendeels is maar een laag, en op een nieuw veld wat verhoogd is kunnen twee lagen wat pas in gebruik is. Met een ja/nee vinkje zou het voldoende moeten zijn! om de selectie aan te geven.
Hoe pak ik dat aan? met een query?

Wat moet dat Ja/Nee veldje doen dan?

Niet met een query... je moet beginnen met velden toe te voegen aan je database.
Een ja/nee veldje dat enkel in de query terug te vinden is, en niet in je tabellen gaat altijd problemen geven.
Overigens blijf ik voorstander om je originele tabel te blijven gebruiken, aangevuld met een jaartal-veld, en een samengestelde sleutel.

Ik ga hier van de volgende veronderstellingen uit:
1- Een begraafplaats zal ook al geen honderduizenden graven hebben... dus de database kan zelfs over de jaren heen niet zo groot zijn.
2- Als je later uit je database een historie wil trekken, waarin je kan zien wie, en hoe lang iedereen waar gelegen heeft, dan is die éne tabel handiger dan verschillende andere historische tabellen.
3- Als je die historische tabel zonder sleutelveld wil hebben, kan je er ook geen subtabellen aan koppelen. Een reeks foto's zal dus al niet meer lukken.
4- Het is gewoonweg eenvoudiger.

Het ja/nee als vinkje ja voor ruimen staat, waarna je een of twee keer per jaar de gegevens verplaatst.

Ben er ook voor om de originele database te behouden.
Maak velden voor:
Bestaand/ geruimd
Nog te ruimen
Of doe dat zelfs in één veld, een keuzeveld dus.
Met een formulier is heel eenvoudig om dat als selectie criterium te gebruiken o dat deel te laten zien wat relevant is.
Vind je dat nog ietsje te lastig... kopieer het hoofdformulier en zet in elke kloon één van de 3 selecties vast. Dus dan heb je 3 formulieren om uit te kiezen:

• Bestaande graven
• Nog te ruimen graven
• Geruimde graven (historische gegevens dus)

Hier mee lijkt me elke export overbodig geworden en je kunt altijd wel een rapport exporteren/afdrukken van elke van die 3 secties.
Je voorkomt hier mee het risico op fouten bij een transfer en als de database aangepast moet worden ben in 1x klaar en hoeft de zgn 2e database niet aangepast te worden als dat nodig zou zijn.

LucHeyndrickx zei:

1- Een begraafplaats zal ook al geen honderduizenden graven hebben... dus de database kan zelfs over de jaren heen niet zo groot zijn.
2- Als je later uit je database een historie wil trekken, waarin je kan zien wie, en hoe lang iedereen waar gelegen heeft, dan is die éne tabel handiger dan verschillende andere historische tabellen.
3- Als je die historische tabel zonder sleutelveld wil hebben, kan je er ook geen subtabellen aan koppelen. Een reeks foto's zal dus al niet meer lukken.

Klik om te vergroten...

Daar vergis je je echt in . En eigenlijk punt 4 dus ook. Dit is echt ingewikkelde materie, met heel veel historie die je beter niet in je productie kan hebben staan.

route99 zei:

Ben er ook voor om de originele database te behouden.

Klik om te vergroten...

Tenzij je zelf ooit een database voor begraafplaatsen hebt beheerd, moet je voorzichtig zijn met dit soort uitspraken.