Hoe kan ik tabellen en hun gerelateerde tabellen in een keer kopieren

Status
Niet open voor verdere reacties.

Chrelske

Verenigingslid
Lid geworden
5 apr 2016
Berichten
24
Alle bij voorbaat bedankt voor je hulp.

Ik heb een project-database in MS-Access 2013 64 bits.
Meestal als ik een vraag had, heb ik die tot nu toe kunnen opzoeken in verscheidene fora en er was altijd een oplossing voor mijn probleem.
Maar deze keer ik heb overal gezocht maar ik heb tot nu toe geen oplossing gevonden.
Dus ik hoop dat iemand mij kan helpen in deze.
In mijn projecten database heb ik een formulier met verschillende sub formulieren.
Achter elk subformulier zit een tabel. Alle tabellen hebben een één tot veel relatie met elkaar.

Relaties van Verkoopbonnen.jpg
calculatie formulier.jpg

Elk subformulier heb ik een letter gegeven. (Alleen maar om het duidelijk te maken welke tabel verbonden is aan welk subformulier)
En op de afbeelding van het formulier staan ook deze letters.
Wat ik wil nu bereiken is dat wanneer ik een record selecteer in het formulier A, en dan klik op de knop Kopiëren,
alle records moeten worden gekopieerd van alle subformulier in een nieuw record in hetzelfde project.

Met andere woorden, er moet een nieuw record worden toegevoegd in vorm A, met alle gegevens die ook in de oude record aanwezig waren, met inbegrip van alle records van de onderliggende tabellen.
Ik weet echt niet hoe dit te bereiken.
Ik denk dat de enige manier is om dit te doen is met VBA.
VBA is geen probleem, ik heb het meerdere keren toegepast (ik bedoel, ik heb verschillende codes gekopieerd en gebruikt in het verleden.
Persoonlijk ben ik geen programmeur, maar het is toch altijd gelukt om het werkbaar te maken in mijn database).
Dus als er iemand is die mij kan helpen, dan zal ik echt waarderen.

Alvast bedankt voor je reactie,

Chris van der Haar
 
Wat ik wil nu bereiken is dat wanneer ik een record selecteer in het formulier A, en dan klik op de knop Kopiëren, alle records moeten worden gekopieerd van alle subformulier in een nieuw record in hetzelfde project.
Met andere woorden, er moet een nieuw record worden toegevoegd in vorm A, met alle gegevens die ook in de oude record aanwezig waren, met inbegrip van alle records van de onderliggende tabellen.
Waarom zou je dat in godsnaam willen? Dat druist werkelijk tegen elk goed gebruik in databaseland in...
Maar goed, het is jouw database. Je probleem kan best met een serie van toevoegqueries worden opgelost, maar het is beter om het met VBA te doen. Om te beginnen: de huidige records zijn gekoppeld op basis van een unieke Nota_ID. Maak je een kopie van dat eerste record, dan krijg je dus een nieuw NotaID. Dat zul je moeten opvragen, want bij de volgende actie moet je eerst de records selecteren van het oorspronkelijke NotaID, en middels een toevoegquery (persoonlijk zou ik het via een Recordset doen) de records die je in tabel B selecteert op basis van het oude NotaID moeten toevoegen aan Tabel B met het nieuwe NotaID. Dat levert in Tabel B dus een aantal nieuwe records op, met unieke TussengroepID's die je ook weer af moet vangen en hergebruiken in de kopie actie op tabel C. Dat hele proces (oude ID opzoeken, Records toevoegen, Nieuwe ID's opzoeken, tabel filteren, selectie toevoegen met nieuwe ID) moet je dus een aantal keer herhalen.
Maar ik denk, als ik je vraagt zo lees: je workflow deugt niet :).
 
Beste OctaFish,

Bedankt voor je snelle reactie.
Het lijkt misschien een beetje onzinnig om een bestaande calculatie in zijn geheel opnieuw te kopiëren in hetzelfde of een ander project.
Maar daar heb ik wel een goede reden voor, het komt n.l. geregeld voor dat een calculatie is gemaakt van een project bv. in 2015.
Nu komt die zelfde klant het jaar daarop weer met een soortgelijk project.
Wat is er dan makkelijker om het project van 2015 in z'n geheel te kopiëren en dan met een paar aanpassingen voor dit jaar weer te hergebruiken.
dat scheelt ons soms wel honderd artikelegels opnieuw invoeren.(maar ook in hetzelfde jaar willen we graag de hele calculatie kunnen kopiëren en aanpassen).

Je wilt niet weten hoe vaak we een calculatie/offerte moeten aanpassen.(en soms willen we de eerste calculatie gewoon bewaren).

De relaties die ik heb gemaakt in de verschillende tabellen dat druist toch niet in tegen elk goed gebruik in databaseland?
Ik begon me al zorgen te maken na je eerste opmerking:confused:

Hopelijk kan je me nu je wat meer weet een beetje op weg helpen met de VBA code die ik daarvoor moet gebruiken.
Ik krijg het nog wel voor elkaar om als er maar een record is te kopiëren maar als er meerdere records zijn met meerdere records in sub tabellen raak ik echt het spoor bijster.

Ik zou het zeer op prijs stellen als je bv. kan aangeven wat voor code ik moet gebruiken.

Alvast bedankt
 
Ik denk nog steeds dat je op een (gedeeltelijk) verkeerde weg zit. Als je veel dezelfde handelingen/records nodig hebt, zou ik daar een sjabloon van maken. In dat sjabloon leg je dan alle vaste onderdelen vast, en als je dan een nieuw project het, maak je één hoofdrecord op basis van de sjabloon. Je kiest dan uit een keuzelijst een projecttype dat dan de benodigde records genereert.
Wil je jouw weg doorzetten, dan zou ik een voorbeeldje posten, want je snapt denk ik wel dat ik voor dit soort specifieke zaken geen code heb liggen :).
 
Het idee van een sjabloon is helemaal niet gek, maar elke calculatie is per project weer anders.
De namen van de hoofdonderdelen zijn anders, en er kunnen andere onderdelen bij gemaakt zijn.
En de artikelen per onderdeel zijn zeker bij elke calculatie anders.

Als ik een nieuwe calculatie maak dan gebruik ik wel de records uit een tabel waarin de standaard onderdelen zitten waar een calculatie uit moet bestaan.
Die is altijd in het begin hetzelfde bij elke calculatie, maar als er extra onderdelen bij een calculatie worden aangemaakt dan moeten die ook worden mee gekopieerd.

Je vraagt mij om een voorbeeld te posten, maar ik wou dat ik zo vaardig was om dat te doen.(VBA is niet geheel mijn sterkste kant)
Misschien wil je toch voor mij eens kijken of je niet iets kan maken met een iets eenvoudiger opzet.
Ik zou al geholpen zijn als ik wist hoe je d.m.v. VBA 2 records in tabel-1 kan kopiëren die elk 5 sub-records in tabel-2 hebben.
Dus hoe kan ik door die 2 records loopen zodat er 2 nieuwe ID's in tabel 1 worden aangemaakt, die weer gebruikt kunnen worden voor de 2 x 5 nieuwe gekopieerde records in tabel-2?
Het eerste nieuwe ID in tabel-1 moet dan de 5 records kopiëren in tabel-2 die horen bij het eerste reeds bestaande ID van record 1 in tabel-1
En het tweede nieuwe ID in tabel-1 moet dan de 5 records kopiëren in tabel-2 die horen bij het tweede reeds bestaande ID van record 1 in tabel-1

Sorry dat ik niets heb om te posten maar ik heb geen idee waar ik moet beginnen.
 
En nu geef je zelf al aan dat het eigenlijk onzinnig is om een compleet project te kopieëren!
 
Alleen als er een compleet nieuwe calculatie wordt gestart van een compleet nieuw project begin ik met een soort van template met voorgebakken regels uit een tabel.
Maar juist als een project met kleine wijzigingen uit bv. vorig jaar ook weer een nieuw project wordt in dit jaar,
is het enorm handig als juist dat project in zijn geheel gekopieerd kan worden.
En als het project gekopieerd is en er zijn maar een paar kleine wijzigingen,
dan hoef je maar een paar regels aan te passen en dan heb je voor dit jaar weer een compleet bijgewerkt calculatie.

Je probeert me er steeds van te overtuigen dat het onzinnig is van wat ik aan het doen ben,
maar echt ik heb hier lang over nagedacht het kan niet anders als je snel een project van vorig jaar wilt gebruiken in dit jaar.

Hopelijk wil je toch nog iets voor me betekenen en een aanzet geven welke kant ik op moet.
 
Wat voor jou duidelijk is, is dat voor ons niet altijd. Wij kennen jou db niet, dus wij moeten het doen met wat je ons vertelt. Op basis daarvan krijg je ook de hulp. Lijkt me ook logisch... Hoe vollediger je bent, en een voorbeeld database helpt daar enorm bij, hoe beter de hulp :).
 
Sorry dat ik niet geheel duidelijk was, en misschien nog niet ben hoor.(bij voorbaat mijn verontschuldiging).
De database die ik gebruik is in z'n geheel wel erg groot, vandaar dat ik een gedeelte heb verwijderd.
Alleen het formulier en de tabellen/query's waar het om gaat zitten er natuurlijk nog in.(van sommige query's wist ik niet zo snel meer de functie, die zitten er ook nog in).

Het formulier waarmee opgestart wordt is het formulier waarin de eerste calculatie zit die gekopieerd moet worden.
Op het formulier zit een knop kopiëren. de bedoeling is dan als ik daar op klik de gehele calculatie(die op dat moment is geselecteerd) inclusief alle gegevens op alle subformulieren worden gekopieerd.
Er moet dan een calculatieregel bijkomen in Sub form-A. Vanaf dat moment is de nieuwe calculatie leidend en kan men nu daarin de gewenste aanpassingen doen.
Het is nl. handig om de eerste calculatie te behouden omdat het nogal eens voorkomt dat een klant na veel wikken en wegen toch beslist o nee doe toch maar de eerste opzet.

Hoe upload ik een rar bestand van 3,6MB als voorbeeld?
Ik zie nu dat het maar 100kb mag zijn.
 
Ik zou hem op en filetransfer als Wikisend.com zetten. Dat is het minste werk.
 
Dit is geen klus voor een regenachtige woensdagmiddag; meer iets voor een taakstraf van een paar weken :). Als een db zo complex in elkaar zit, dan wordt het in ieder geval erg lastig om korte termijn hulp te geven. Je zult dus enig geduld moeten hebben...
 
Voorlopig ben ik al blij dat je er überhaupt naar wilt kijken.
Zoals ik al zij dit is een moeilijke klus en zelf weet ik gewoon niet waar te beginnen met zoveel geneste tabellen.
Deze database is in de loop der jaren zo uitgebreid geworden. En elke keer komen er weer dingen bij(Totaal 90MB Front_End en 45MB Back_End).
Voor nu heb ik de benodigde tabellen als lokale tabellen weer terug geïmporteerd.

Dus ik wacht geduldig af en als het je lukt ben ik je wel een biertje of wat verschuldigd. :o
 
Hoe kan je frontend nou 2 keer zo groot zijn als je backend? Maar inderdaad, er zitten tabellen en koppelingen in waarvan ik mij afvraag wat daar nou het nut van is. Mijn eerste indruk was in ieder geval: (en laat ik het zachtjes zeggen) slecht genormaliseerd. Bovendien stikt het van de velden met aan tabellen gekoppelde keuzelijsten, en dat is echt iets dat er bij mij gelijk uitgehaald zou worden. Keuzelijsten op basis van tabellen/queries horen niet thuis in een tabel. Alleen keuzelijsten op basis van waarden mogen wat mij betreft. Die heb je ook, dus die zou ik zelf laten zitten. De rest? Allemaal omzetten naar tekstvelden!
 
Laatst bewerkt:
Wordt je database er trager van als je keuzelijsten gebruikt waarvan de waarden uit een tabel komen?
Als dat zo is dan ga ik er nog een keer goed naar kijken.
Ik gebruik een keuzenlijst ook nog wel eens meerdere keren in verschillende tabellen, bv. keuzelijst Ja;Nee;n.v.t;wachten;etc,
Als dan de waarden veranderen dan hoef ik dat alleen in de tabel te doen.
Op alle gebruikte tabellen en formulieren is dan gelijk deze keuzelijst aangepast.

En ik gebruik een keuzelijst ook nog wel eens, als ik bv. "De heer" of "mevrouw" kies deze keuze ook gelijk voor bv. de Engelse benamingen geld.
Keuzelijst.JPG
Is deze aanpak dan ook af te raden en is daar een betere manier voor?
Ik ben jaren geleden ook zomaar begonnen met het opzetten van deze database, en er toen wel veel over gelezen.
Maar gaande weg kom je toch weer steeds dingen tegen die anders of beter hadden gekund.

Je gaf ook nog aan dat de database slecht is genormaliseerd.
Maar ik was er toch echt van overtuigd dat alle informatie nergens twee keer voorkomt.
Alle sub tabellen zijn met ID's met elkaar verbonden.
Dus als een beurs meerdere orders heeft en de beursnaam veranderd o.i.d. dan verander ik de naam in de tabel Beurzen.
Dan is gelijk voor ieder ordernummer ook de beursnaam veranderd.

Maar als je ergens ziet waar ik echt de fout mee in ga dan hoor ik dat graag en ga ik er wat mee doen.
 
Worden tabellen trager met (veel) keuzelijsten op tabellen? Zou mij niks verbazen. Maar dat is niet de reden om ze te vermijden. Die is heel simpel: met een keuzelijst zie je nooit meer wat er nu echt in het veld is opgeslagen. Doorgaans verberg je het ID veld uit je keuzelijst om te kunnen zoeken op naam bijvoorbeeld. In de tabel sla je dan het ID op, maar je ziet dus de naam. En dat krijg je ook in een query terug. Wil je nu filteren op een bepaalde persoon, dan heb jij geen idee welk ID dat is geweest, je ziet alleen de naam. Erger wordt het nog als je de tabel/query gaat exporteren; nu krijg je de ID wél te zien. En in die export wil je nou juist weer de naam zien! Kortom: alleen maar ellende en getob. Mijn standpunt is simpel: in een tabel moet je te allen tijde de echte waarden kunnen zien die je opslaat. Keuzelijsten, om makkelijker klanten etc. te kunnen kiezen, zet je op formulieren en nergens anders. Daar horen ze ook thuis.

Het plaatje dat je nu laat zien, geeft m.i. ook een verkeerde tabel weer. Het is prima om verschillende talen te gebruiken in een tabel, maar jij hebt nu voor elk veld minstens 3 velden nodig als je 3 talen hebt, en 4 velden als er een taal bijkomt. Dat zou ik dus totaal anders doen. Bij mij krijg je een tabel met voor elk attribuut één veld, en daarnaast een veld Taal. Uiteraard ook een TaalID veld als sleutelveld. In mijn formulieren en rapporten kies je dan op basis van een specifiek veld (ik kan mij voorstellen dat je bij een rapport dan Duits kiest als de factuur naar Duitsland gaat) de Duitse tekst te zien, bij Engels de Engelse tekst. De grap is: ik hoef ook maar één rapport of formulier te maken, want ze gebruiken allemaal hetzelfde veld voor Aanhef etc. Jij moet voor elke taal een apart rapport maken.

Kijk, en dát is dus een voorbeeld van slecht normaliseren t.o.v. goed normaliseren! Slecht genormaliseerd is een tabel als je voor één attribuut (Titel, Aanhef etc) meerdere velden nodig hebt en bij elke wijziging/uitbreiding in de tabel moet gaan wroeten om dat op te lossen. Krijg jij Marokko als klant erbij, dan kun je daar niets mee zonder dat je de tabel aanpast; je moet dan weer een volledige set velden toevoegen. En En je queries uitbreiden. En er een rapport bijmaken.... En weet ik veel wat nog meer. In mijn goed genormaliseerde tabel voeg ik één record toe met de Marokkaanse vertalingen, en alles is klaar en werkt nog steeds prima.
 
Zo zie je maar, je bent nooit te oud om te leren.
Ik ga kijken of ik daar alsnog wat mee kan.
Het zal niet meevallen om dit nog achteraf aan te passen.
Het is zomaar gebeurt dat een bepaalde query niet meer werkt als je een veld veranderd o.i.d.
Leuk om nu eens te sparren met iemand die er veel vanaf weet.
Had ik misschien jaren geleden al eens moeten doen. :(
 
Ik ken het probleem :). Aanpassen van een bestaande db levert vaak meer ellende op dan gewoon helemaal opnieuw beginnen. Totdat de nieuwe db goed werkt, laat je de mensen dan gewoon in de oude werken en ondertussen bouw je dus door aan je vernieuwde ontwerp. Uiteindelijk ben je daar waarschijnlijk beter mee af dan het spaghetti werk dat je nu vermoedelijk nodig hebt :).
 
Eigenlijk wil ik de database ooit een keer als een webapplicatie laten werken.
Dan moet ik toch helemaal opnieuw beginnen.
Nu kunnen de mensen er alleen bij als ze inloggen met Remote Desktop en dan MS-Access opstarten etc.
De database zelf is vanaf dat moment ook niet beveiligd o.i.d., iedereen ziet en kan hetzelfde doen.
Eigenlijk wil ik voor iedere gebruiker kunnen instellen wat ze zien.(dat zal een hele klus worden).
maar mijn doel is eigenlijk dat ze overal op elke PC met internet kunnen inloggen.

MS-Access kan ook Web databases maken maar ik denk dat de mogelijkheden die ik nu heb ingebouwd op die manier niet allemaal kunnen.
Ik las ook dat je dan geen gebruik meer kan maken van VBA, hoe moet je dan alle acties die er nu inzitten realiseren?

Je hebt tegenwoordig ook MS Azure SQL databases in de cloud, denk je dat dat de goede weg is om gegevens in de cloud te gebruiken,
of kan je beter op onze eigen server een SQL-Server inrichten en die dan benaderen via webservices.
Je hebt ook nog AJAX webapplicaties is dat dan de manier om een snel werkend systeem op te zetten.

Heb jij ook ervaring in deze richting en wat zou je mij adviseren om te doen.
Wat het ook wordt, ik zal mijn borst nat moeten maken denk ik, want dit wordt denk ik een klus die voor één man een dagtaak gaat worden.
Eigenlijk doe ik dit nu tussen m'n gewone werk door.(maar ik klaag niet hoor, heb dit ooit zelf aangekaart om te maken).
 
Een web database draait volgens mij alleen onder SharePoint, en als je dat niet gebruikt heb je dus geen webdatabase. Het is overigens niet mijn specialiteit; ik geef alleen maar weer wat ik lees.
De database zelf is vanaf dat moment ook niet beveiligd o.i.d., iedereen ziet en kan hetzelfde doen. Eigenlijk wil ik voor iedere gebruiker kunnen instellen wat ze zien.
Rechten instellen in een db met meerdere gebruikers is sowieso een goed idee; je hebt nu blijkbaar alles open staan en dat zou ik ook niet doen. Is overigens niet zo lastig als je denkt; kwestie van de juiste rollen maken en personen aan een rol koppelen.

Nu kunnen de mensen er alleen bij als ze inloggen met Remote Desktop en dan MS-Access opstarten etc.
Werken op afstand lijkt mij, zeker in bedrijfsomstandigheden, de beste werkwijze omdat je ook met je beveiliging zit. Als je van afstand inlogt op je werk (wij gebruiken daar Citrix voor) werk je dus veilig, en je hebt alle functionaliteit die je wilt hebben en afdwingen. Ik zie het probleem (voor de gebruiker) dus niet.

Iets anders is het als je een webwinkel hebt; dan wil je de webdata natuurlijk ook in je winkel hebben en de bestellingen in je database. Dat kan uiteraard prima, maar niet met Access. Dan moet je echt helemaal overnieuw beginnen met een MySQL database bijvoorbeeld.

Nu kunnen de mensen er alleen bij als ze inloggen met Remote Desktop en dan MS-Access opstarten etc.
De database zelf is vanaf dat moment ook niet beveiligd o.i.d., iedereen ziet en kan hetzelfde doen.
Eigenlijk wil ik voor iedere gebruiker kunnen instellen wat ze zien.(dat zal een hele klus worden).
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan