Office: (Office 2016) VBA Fehler auf 1 von 3 Rechnern

Hallo lybserv,

warum arbeitest du mit mehreren Excel-Instanzen? Das würde ich zuerst auf eine Instanz reduzieren und anstatt SaveCopyAs() reicht auch ein SaveAs().

Hinweis:
man könnte an eine Funktion auch Argumente übergeben und eine Funktion kann auch etwas zurückliefern.
Dann bräuchte man auch nicht mit Active ... arbeiten. *wink.gif*


Ulrich

 

Hey ihr beiden

@Accessbeginner
Ich habs mal ausgetauscht - auf PC 1+2 funktioniert es weiterhin, auf 3 unverändert, der gleiche Fehler

@knobbi
Hmm, ehrlichgesagt: Es hat ohne Murren funktioniert, ich habe alle meine Dateien sauber damit speichern können *wink.gif* SaveCopyAs nutze ich, damit die Quelldatei/Vorlage nicht überschrieben wird..

Frei nach dem Motto "never touch a running system" wollte ich es dann heute auf den FirmenPC packen (hab ja alles ausgiebig getestet) .. und dann kam das böse Erwachen *frown.gif*

 

Hallo lybserv,

wenn du doch nichts verbessern oder ändern möchtest, warum fragst du dann hier noch nach einer Lösung oder Hilfestellung? Funktioniert dein Code oder nicht?

Wenn man so leger programmiert, kommt das "böse Erwachen" meistens automatisch, wenn sich die Rahmenbedingungen ändern. Programme so zu schreiben, daß das nicht passiert, ist die hohe Kunst und dazu gehört auch ein Stück weit Erfahrung. Diese geben die Helfer hier ja gerne weiter, man muß sie natürlich auch annehmen wollen.

Insgesamt hast du jetzt wahrscheinlich mehr Zeit mit Fehlersuche verbracht als eine kleine Codeanpassung und -bereinigung gedauert hätte.

Die Unterschiede sind dir bekannt? Wieso wird mit SaveAs die Vorlage verändert? Mit SaveAs wird die verändert Vorlage automatisch deine neue Arbeitsdatei.
Bei deiner Lösung wird die Vorlage als neue Datei gesichert, das aktuelle Workbook geschlossen, wobei die Änderungen verworfen werden müssen, und anschließend wird das zuvor bereits geänderte Workbook wieder in den Speicher geladen. Umständlicher und fehlerträchtiger geht es nun nicht mehr.

Einfach mal die Arbeitsabläufe anschauen, wo etwas doppelt gemacht wird und dieses dann eleminieren. Gleichzeitig werden dann dadurch auch automatisch potentielle Fehlerquellen ausgeschaltet bzw. vermieden.

Übrigens: ein Fehlerbehandlung bei IO-Operationen ist für eine Anwendung unter Produktionsbedingungen "recommended".


Ulrich

 

Das Austauschen alleine reicht nicht aus. Du darfst das "w" nicht von hand auf Gross "W" Schreiben.

Auch wenn du im Code ein klein "w" schreibst wird es im VBA automatisch in Gross "W" ersetzt. Was bei dir nicht der Fall ist.

Das heisst wenn "Excel.workbook" nicht automatisch als "Excel.Workbook" umgeschrieben ist, dann ist was nicht in Ordnung.

Ich habe beispielsweise dein Code bei mir eingefügt und schon wurde aus "Excel.workbook" >>> "Excel.Workbook"

Meines Wissens liegt dort der haken.

 

Hallo knobbi,

nicht falsch verstehen - ich werde den Code wohl jetzt anpassen (müssen). Meine ursprüngliche Frage war ja nur, warum es auf 2 Computern läuft und auf dem 3. überhaupt nicht, trotz selber Rahmenbedingungen.

Ich schaue jetzt mal, dass ich nur noch eine Instanz verwende und benutze die SaveAs Funktion, die macht ja anscheinend doch genau das, was ich möchte *wink.gif*

@Accessbeginner: Verstehe. Schaue ich mir auch an, nur meinst du nicht auch, dass der Code garnicht laufen dürfte, wenn solch ein genereller Fehler da drin wäre?

Bei 300 einwandfreien Durchläufen kann man ja nicht von Zufall oder Glück sprechen.. *wink.gif*

 

Ob Groß oder Klein, spielt bei VBA keine Rolle.
Wenn es eine Rolle spielen würde, wäre der Code (bei Nutzung von Option Explizit) nicht kompilierbar und auch nicht startbar.
Ich hab bei mir aber mal versucht das w auf klein zu ändern (Acc 2019).
Das wird sofort wieder korrigiert und es ist mir gar nicht möglich, das "w" klein zu halten.

Das Problem ist einfach fehlendes Basiswissen, um durch das Debuggen das Problem zu lokalisieren.

LG Markus

 

Da stimme ich dir zu, mit Einzelschritten etc. hab ich mich noch nicht beschäftigt.. werde ich mir auch noch zu Gemüte führen *wink.gif*

 

Ja das ist wohl höchste Zeit.
Denn ohne kann man wohl kaum programmieren.
Die User in den Foren glauben alle programmieren ist "Kopieren von Code".
Dabei geht es in erster Linie darum zu verstehen was man tut und möglich Fehler vorherzusehen und nicht zuzulassen.
Dazu gehört dann auch ein Fehlerhandling, das im Notfall eingreift und bei dir fehlt.
Eine Runtimeversion würde einfach abstürzen und sich verabschieden.

 

Ich hab da wirklich ziemlich viel unnötigen Aufwand betrieben *wink.gif*

Die savecopy Funktion hab ich komplett rausgeworfen, der Code steht jetzt einfach mit im Private Sub

Code:

Die Rechnung am Ende generiere ich jetzt mit

Code:

Quasi muss ich nicht mehr mit mehreren Excel Instanzen hantieren, es wird immer nur eine genutzt. Keine Closes / Quits mehr, keine verwaisten Excel Prozesse - alles in einem Abwasch *wink.gif* und gefühlte 30 Codezeilen weniger als vorher

Und das schönste, es funktioniert jetzt auf allen 3 Computern *biggrin.gif*

 

Hallo lybserv,

dann hat sich der Aufwand ja gelohnt. Weniger Codezeilen sind zudem weniger wartungsintensiv und besser zu überblicken.

Ulrich