Query en formulier kopiëren van ene naar andere database

[handyhanky]

Ik wil het volgende: m.b.v. een (autoexec)macro een query en een een formulier kopiëren naar een andere (doel)database.
In de brondatabase heb ik dus de macro, de query en het formulier.
In de doeldatabase komen de query en formulier ook voor en kunnen worden overschreven.
Iemand een voorstel voor een stukje VBA-code?

 

[OctaFish]

Waarom zou je dat doen? Je kunt ze razendsnel slepen naar de nieuwe db. Ben je in 6 seconden klaar. Ik kan snel programmeren als het moet, maar dat trek ik toch echt niet...

 

[handyhanky]

Kan ik ook (snel kopieren) maar wil voor minder handige gebruikers een soort van patch-database maken die ze alleen hoeven te openen om een nieuwe query en/of formulier te "installeren"

 

[OctaFish]

Lijkt mij dat je beter een nieuwe Frontend kunt uitrollen waarin de bijgewerkte/nieuwe formulieren zitten. Jouw idee gaat alleen werken als je vanuit de frontend connectie kan maken als gebruiker met de backend (of een hoofd frontend) middels ADO of DAO connecties, en dat is a) dus een hoop programmeerwerk en b) lastig te onderhouden, want hoe check je de nieuwe formulieren? Als je een forumulier exporteert of importeert, zet Access automatisch een volgnummer achter het nieuwe formulier als de naam al bestaat, dus je moet eerst de bestaande formuileren verwijderen, en daarna exporteren/importeren.
Eigenlijk kun je het alleen ook maar goed laten uitvoeren als import, omdat je geen formulieren kunt vervangen die een gebruiker al open heeft staan. Je moet dus ook nog eens de gebruikers langs om te controleren dat de db niet actief is.
Een frontend kun je automatisch laten uitrollen als een gebruiker inlogt, en kost je dus verder helemaal geen werk. Je maakt de aanpassingen, en zorgt ervoor dat de nieuwe db bij het inloggen wordt geïnstalleerd.

 

[handyhanky]

Ja zo doe ik het normaal ook maar ik wilde het nog gemakkelijker maken voor de gebruiker. Eenmaal een stukje code gemaakt kan ik eenvoudig aanpassen voor een volgende keer. Dus in principe
"eenmalig" werk. Nog handiger wordt het als je met code velden kan toevoegen aan tabellen in de backend. Hele tabellen maken in de backend met code lukt me wel.

 

[OctaFish]

Nog handiger wordt het als je met code velden kan toevoegen aan tabellen in de backend.

Je bent ofwel lui, ofwel heb je geen benul van automatisering... In Access is het toevoegen van een extra veld nog wel te doen met VBA, maar dan? Hoe ga je dat vullen? Je moet daarna je formulieren aanpassen, je queries, je rapporten... Dat alles valt onder Beheer, en is nu eenmaal grotendeels handwerk. Daarom is het bijzonder handig als een database beheerder weet wat-ie doet.
Jouw wens is vergelijkbaar met een knop in je auto waarmee je automatisch een lekke band kan vervangen (oude band eraf, nieuwe uit de kofferbak, nieuwe er op, oude naar de bandenservice etc). Zal nog wel een tijdje duren voordat die knop in de gemiddelde auto zal zitten. Wellicht de knop nog wel, maar werkend?

 

[handyhanky]

Normaal waardeer ik jou bijdragen zeer. Dit keer heb je de vraag vast verkeerd begrepen. Dat maak ik op uit de mislukte metafoor van de lekke band. Het zal aan mij liggen dat ik onvoldoende heb geduid wat mijn beweegredenen zijn inzake deze query/formuliervraag. In ieder geval herken ik me niet in de door jou gesuggereerde klassificaties, noch het 'lui' noch het 'geen benul van'. Ik ga nu maar zelf het wiel uitvinden want inmiddels is dit een metadiscussie aan het worden en gaat het niet meer over de inhoud. Daar is het forum volgens mij niet voor bedoeld. Maar ook dat kan aan mij liggen. Succes verder.

 

[OctaFish]

Als je niet goed uitlegt wat je vraag/probleem is, dan kan je niet verwachten dat er bruikbare antwoorden komen. Als ik mijn laatste antwoord teruglees, dan was hij inderdaad een beetje aan de harde kant, daar geef ik je gelijk in. Dus als ik je beledigd heb: excuses. Maar je wekte de indruk dat je je zaken niet helemaal goed hebt ingericht, en naar de makkelijkste uitweg zocht.
Overigens, om weer on topic te gaan, (volgens mij gaf ik wel degelijk ook antwoord op de vraag trouwens) is het uitrollen van een nieuwe versie de gemakkelijkste methode. Om met VBA allerlei objecten aan te maken/kopieëren naar andere databases (want het gaat neem ik aan om meer dan één gebruiker) vergt nogal wat programmeerwerk. En de vraag lijkt mij gerechtigd of je die tijd er wel in moet steken, als het zoveel makkelijker kan.
Maar dat is uiteraard aan jou. Ik denk niet dat er veel mensen zijn die daar kant-en-klare code voor hebben liggen, omdat het zo'n onhandige werkwijze is; waarom zou je daar als programmeur tijd in hebben gestoken? Ik in ieder geval niet.

 

[handyhanky]

Prettige reactie, dank je. Een uitleg van de problematiek:

De backend db kan ik niet altijd op afstand benaderen. Als ik daar wijzigingen in wil aanbrengen dan moet ik naar de locatie toe met de auto, of ik moet iemand vragen om de backend naar me te mailen. Ik doe dan de aanpassing en mail het bestand terug. Dat werkt. Nadeel is het heen-en-weer gemail dat bovendien soms stuit op virusscanners die bepaalde bestandsformaten weigeren door te laten. Dan moet ik de handlanger op afstand uitleggen hoe de virusscanner te overtuigen dat het bestand gemaild mag worden. Met sommige mensen is dit echt heel lastig!

Met een stukje code hoeft dit niet meer. Ik mail dan een bestandje met een autoexec macro of stop het in een nieuw frontend. Ik kan het zo mooi maken als ik wil:
- controle of de wijziging al is gedaan (tabel of veld bestaat)
- controle of de db in gebruik is
- nacontrole of wijziging goed is gegaan
- markering maken zodat wijziging slechts eenmaal gebeurt

Public Sub Veldtoevoegen()

'hier controle of db in gebruik is en of de wijziging al is gedaan

Dim w As Workspace
Dim d As Database
Dim TABEL As Object
Dim VELDNAAM As String
Dim NIEUWVELD As Object

Set w = DBEngine.Workspaces(0)
Set d = w.OpenDatabase("F:\mapnaam\data1.mdb")

Set TABEL = d.TableDefs("T_Memo") 'naam van de tabel

VELDNAAM = "strNaampje" 'naam van het nieuwe veld


Set NIEUWVELD = TABEL.CreateField(VELDNAAM, dbText) 'soort veld kiezen

TABEL.Fields.Append NIEUWVELD


'hier msgbox met bevestiging


'dbBigInt Groot geheel getal
'dbBinary binair
'dbBoolean Boole - waarde
'dbByte Byte
'dbChar Char
'dbCurrency Valuta
'dbDate Datum / Tijd
'dbDecimal Decimaal
'dbDouble Double
'dbFloat Drijvend
'dbGUID Guid
'dbInteger Geheel getal
'dbLong Lang
'dbLongBinary Lang binair (OLE-object)
'dbMemo Memo
'dbNumeric Numeriek
'dbSingle Enkel
'dbText Tekst 255 lang
'dbTime Tijd
'dbTimeStamp Tijdstempel
'dbVarBinary Varbinary

End Sub

Dan de frontend aanpassingen:
Een nieuwe frontend maken en mailen is goed te doen.
Mijn overwegingen om alleen een query/formulier "over te zetten":
- het gebruiksgemak voor de handlanger, zelfde als bij backend-aanpassing beschreven
- het gaat nogal eens mis met de 'verwijzingen' met name als er met oudere access-versies of meerdere access versies door elkaar wordt gewerkt. De frontend opmaken in een oude accessversie biedt niet altijd soelaas.
Misschien zijn er betere oplossingen maar ik dacht dus aan een patch.mdb die de handlanger slechts eenmaal hoeft te openen waarmee de update van query/formulier gerealiseerd is.