Office: (Office 2016) Application.SaveAsText in anderer DB

Ich wollte die Application.SaveAsText Methode auf eine andere DB anwenden und komme da momentan kein Stück weiter.

Application.SaveAsText acForm, "Formularname", CurrentProject.Path & "MeinFormular.txt"

Ich versuche es derzeit über einen Umweg:

Code:

app.Access.SaveAsText gibt's ja nicht, daher versuch ich das Formular in meine Ausgangs-DB zu kopieren und wollte es dort dann "SaveAsTexten".

Das Öffnen der anderen DB klappt, das AutoExec-Makro verursacht aber eine Fehlermeldungen (Nav-Leiste sperren etc.)
Das ja nicht so schlimm. Die schließe ich einfach.

Allerdings führt das bei der .CopyObject Methode zu

Bau ich ein MsgBox "Warten" davor -> Keine Auswirkungen

Baue ich ein .OpenForm "Test_Form" davor kommt

Bau ich ein .OpenForm "XY_Form" davor kommt

Ich scheine mit diesem Umweg somit auf einem Holz zu sein und daher nun hier die Bitte um Hilfe.
Jemand eine andere Idee, wie ich auf ein Formular aus einer anderen DB Application.SaveAsText anwenden könnte?

:)

 

[...]
app.Access.SaveAsText gibt's ja nicht,

Doch, gibt es, funktioniert und löst dein Problem.

 

Bist du sicher?
Es wird mir in der Cursorliste, die nach dem . erscheint nicht angezeigt.
Egal hab's natürlich ausprobiert. (warum mach ich sowas eigentlich nie auf Anhieb?!)

Jedenfalls hat nicht so funktioniert. Er meckert jedenfalls nicht wegen der Methode sondern:

Code:

Laufzeitfehler '0' Reservierter Fehler

Habe auch die AutoExec-Makros in der Test-DB mal deaktiviert trotzdem kommt es.

 

Da du verschiedene Schreibweisen verwendest.

Die richtige ist:

app.SaveAsText

Im ObjektKatalog kannst du im Kontextmenü "Verborgene Elemente anzeigen" aktivieren, dann wird die Eigenschaft im ObjektKatalog angezeigt und ist auch für die Intellisense verfügbar.

LG Markus

 

\@sonic8,
weisst du wie man eine Methode/Property in einer eigenen VBA Klasse als "verborgen" erzeugt.

 

Hallo,
mich würde mal interessieren, was du dir von der exotischen Funktion versprichst?

Ansonsten finde ich den Weg über den Import (in die aktuelle DB) gar nicht so schlecht, da eine neue Accessinstanz etwas "bugby" und auch nur in der Vollversion verfügbar ist.
Allerdings ist CopyObject der falsche Weg. Dafür gibt es docmd.TransferDatabase.

 

Imgrunde bau ich mir grad sowas wie das hier:
Import/Export Utility for MSAccess Import/Export Utility for MSAccess

Das hab ich grad gefunden, und sieht mega aus.
Natürlich mach ich die Sache für mich weit weniger komplex. *biggrin.gif*
Und es soll für AC 2016 funktionieren.

Danke. Wieder was gelernt. Ja jetzt taucht sie auf, dann schaff ich den Rest sicher auch gleich *Smilie

 

Hallo,

Ja und wozu brauch man so was?

Der Umweg über den Import in die aktuelle Datenbank sollte auf jeden Fall funktionieren.

 

Die Betonung muss wohl auf sollte liegen.
Im Hintergrund nutzen wohl beide Befehle die gleichen Methoden.

Jedenfalls sollte beides funktionieren.
Ansonsten kann man ja durch testen herausfinden, was die Probleme verursacht.

@marinsche
ich arbeite grad an was Ähnlichem.

 

*Kopf auf Tisch knall*

Es läuft und ich weiß woran der Fehler lag. Zuletzt kam "Kein aktueller Datensatz"

Die Testdatei hat natürlich aktivierten Projektschutz und weil im Formular VBA-Code liegt kann ich das Formular selbstverständlich nicht kopieren.

Projektschutz raus und Tada!!

Code:

Danke an alle die mitgeholfen haben. Jetzt bau ich mir das schick mit

Set c = appaccess.CurrentDb.Containers("Forms")
For each ...


@Steffen: Ich bau das so ein bißchen mehr für mich, für instabile Datenbanksrettung. Und weils mir grad Spaß macht :-D

 

\@Markus:
Sehe keinen Grund warum dies nicht funktionieren soll!? Ja und es funktioniert auch (bei mir).

Code:

Ansonsten sehe ich die neue Accessinstanz weiterhin kritisch. Bei mir stürzt Access damit z.B. komplett ab. Der Umweg über Shell() ist da wesentlich zuverlässiger, aber auch einigermaßen komplex.

 

Natürlich funktionieren beide Befehle.
Aber wenn du etwas intensiver damit arbeitest, wirst du merken, dass beide Befehle so wie auch viele andere in gewissen Kontexten nicht funktionieren.

Da geht es dann für mich darum den Grund zu isolieren.

Was meinst du mit dem Umweg über Shell, und welches Problem mit Access Instanzen meinst du?

 

\@Markus:

Wenn das wirklich so wäre, könnte man aufhören zu programmieren.
Wenn Befehle logisch nicht zusammengehören (so wie hier) dürfen sie sich auch nicht beeinflussen.

Für die appAccess.OpenCurrentDatabase Methode brauch es eine 2. Accessinstanz.
Die kann per CreateObject erzeugt werden (dies crasht bei mir und funktioniert nicht mit RT) oder per shell ("msaccess").

 

Jein.
Theoretisch indem du den Flag 40 für das Attribut VB_MemberFlags festlegst. - Praktisch funktioniert(e) das aber nur in VB6 und nicht in VBA. Angeblich wurde dieses Feature für den VBA-Compiler nicht implementiert.

Beispiel wie es in VB6 funktioniert:
Code:

 

Alles klar.
Mit RT habe ich nicht so die Erfahrung.
Öffnen per Shell ist für mich einfach eine Möglichkeit.
Ich wüsste auch nicht, ob ich bei OpenCurrentDatabase Parameter wie CMD usw mitgeben kann.