Datei speichern in neues Verzeichnis

[falken]

etwas oT
Hallo Reinhard,
bin leider im Dauerstress, deshalb komme ich erst jetzt dazu, hier wieder reinzuschauen, sorry.
Vielleicht schaffe ich es ja morgen, den Code etwas übersichtlicher zu gestalten. Zu den modulweit deklarierten Variablen: Das kommt mir gedanklich sehr entgegen, dass es sie gibt.
Deshalb habe ich mich mit dem Übergeben von Parametern von/zu einer sub oder function nie eingehend beschäftigt. Leider fehlt mir auch die Zeit, meinen ProgrammierStil grundlegend zu ändern. In diesem Fall wäre eher das Auslagern der fertigen > Makros in
Add-ins das nächste Ziel. Nicht nur wegen des Speicherplatzes für die noch fehlenden Ordner und jeweils eine vollständige Kopie meiner Vorlagendatei. Aber dazu stelle ich besser eine neue Frage ins Forum, denke ich.
Der leider etwas chaotische Aufbau meines Makros rührt vielleicht aber z. T. auch daher, dass ich möglichst viele bereits erfasste Daten erhalten und einbeziehen will ( ist auch eine Frage der positiven MitArbeiterMotivation, wenn Daten nicht immer wieder erneut eingegeben werden müssen ).
Letztendlich soll ein Teil der auftragsbezogenen Daten aus der „Angebotsliste.xls“ in die neuen Pfad & „Projekt“ & Angebotsnummer & „.xls“ übernommen werden und dort in den einzelnen Registerblättern für weitere technische sowie kaufmännische Berechnungen als Eingangsparameter verwendet werden. Dabei kann es sein, dass das jeweilige Angebot schon als Ordner in der OrnerStruktur des Servers angelegt ist oder in das AngebotsVerzeichnis eingetragen ist. Oder beides. Oder nix von beiden.
Die anderen RegisterBlätter meiner Vorlage „Projekt.xltm“ funktionieren nun schon ganz gut. Sie basieren auch auf erprobten älteren Makros, die ich in die neue Vorlage integriert habe.
Zum Schluss muss ich dann noch überprüfen, ob die Makros auch von 2003er ExcelVersionen verarbeitet werden. … Ich glaube, ich muss ´mal ein paar Leute anmailen, wegen professioneller Unterstützung

Zurück zum Thema:

Ja, das DurchChecken im EinzelSchrittModus hat so lange gedauert - im DurchSchnitt - ungefähr geschätzt.
Habe mich vielleicht nicht so klar ausgedrückt. Tut mir leid, dass ich das nicht eher richtigstellen konnte.

Ich werde den Code erst´mal etwas übersichtlicher schreiben und dann wieder ´reinstellen.
Nochmals vielen Dank für Deine Mühe und Hinweise.
Schönes WochenEnde
Thomas

[falken]

ätzend
Hallo Reinhard,

PS: Das Makro ist echt ätzend geschrieben,

Das ist nicht meine Wortwahl.

Gruß
Reinhard

Finde ich, ehrlich gesagt, auch ein wenig übertrieben >

Thomas

[falken]

Hallo Reinhard,
Du meinst diesen Code?

Sub Ordner_anlegen()
Dim T As Single, Pf As String
If KundenName = „“ Then KundenName = InputBox(prompt:=„Geben Sie bitte einen KundenNamen ein:“, _
Title:=„Ereignisprozedur zu Open“)
OrdnerName = Angebot & „_“ & KundenName
Pf = „\server\daten$\Angebote“ & Ziffer & „“ & OrdnerName
T = Timer
MkDir Pf
While Dir(Pf, vbDirectory) = „“
DoEvents
sleep 200
Wend
MsgBox Pf & Chr(10) & "wurde in ca. " & Format(Timer - T, „#.00“) & „sec angelegt.“
End Sub
?
Versuche ich morgen gerne und melde die Resultate.
Bis dann
Thomas

[falken]

FehlerBehandlungsRoutine
Hallo Stephan,
klingt schon interessant. Danke. Gibt es da einen BeispielCode?
Wo muss man das Makro ablegen? In jedes Modul?
Schönes WE
Thomas

[Stephan_8a4919]

Ich habe z.B. schon öfter
erlebt, dass VBA am Ende eines Strings & „“ vergisst.

Was bedeutet „vergisst“. das klingt so als würde Vba aus
Pfad =„c:\test“
zur laufzeit dann
„c:\test“
machen. das kenne ich nicht.

Beim
Filename für SaveAs hat das dann entsprechend gefehlt und auch
einen Fehler verursacht. Warum das so ist weiß ich nicht, und
das Problem tritt auch nicht immer auf.

Schad, würd gern den Code sehen wo das auftritt.

Ein Original hab ich gerade nicht zur Verfügung.

Zum Speichern benutze ich fast immer einen Pfad, der Jahr-Monat enthält. Das Konstrukt sieht dann so ähnlich aus.

Dim strPfad As String
Dim strDatei As String
Dim strJahrMonat As String

strJahrMonat = Format(Now(), „yyyy-mm“)
strPfad = „C:\Test“ & strJahrMonat & „“
strDatei = „test.xls“

ActiveWorkbook.SaveAs Filename:= strPfad & strDatei

Nun kommt es manchmal vor, dass das Makro anscheinend & „“ am Ende von strPfad „vergisst“. Die SaveAs-Methode muss dann natürlich fehlschlagen. Das Problem zu finden ist schwierig, weil es, in meinen Augen, gar nicht existieren dürfte. Wenn man den Filename stattdessen in einer neuen Variable zusammensetzt, gibt es keine Probleme mehr bzw. falls doch, kann man den Fehler viel schneller finden.

[Thomas_Ramel]

Grüezi falken

Ein Punkt fällt mir einerseits positiv, andererseits negativ auf…

’ AUFRUFENDE DATEI unter neuem Namen speichern
ActiveWorkbook.SaveAs Filename:=Pfad & „Projekt_“ & Angebot &
„.xls“, FileFormat:=xlExcel8, Password:="",
WriteResPassword:="", _
ReadOnlyRecommended:=False, CreateBackup:=False

’ AUFRUFENDE DATEI unter ALTEM Namen speichern
ActiveWorkbook.SaveAs
Filename:="\server\daten$\VORLAGEN\Excel\Projekt.xltm",
FileFormat _

=xlOpenXMLTemplateMacroEnabled, Password:="",

WriteResPassword:="", _
ReadOnlyRecommended:=False, CreateBackup:=False 'für LaufZeit
diese Zeile auskommentieren

Du verwendest hier beide Male korrekterweise die FileFormat-Eigenschaft der SaveAs-Methode, das ist gut so.

Allerdings kannst du dann die Dateiendung komplett weglassen - die wird ja über das Fileformat automatisch zugewiesen.

Das könnte eine Ursache für dein Problem sein.

Ansonsten kannst Du mit ein klein wenig API und MakePath prüfen und dafür sorgen, dass die benötigten Ordner jeweils korrekt angelegt werden.

Wenn es Probleme und Verzögerungen beim Zugriff auf den Server gibt, dann kann es sein, dass der Ordner noch nicht angelegt ist, und die SaveAs-Methode bereits speichern will - dann hilft IMO nichts anderes als Warten und/oder nach dem Anlegen des Ordners prüfen ob er auch da ist und das in einer Schleife vor dem SaveAs Befehl.

Mit freundlichen Grüssen

Thomas Ramel

• MVP für MS-Excel -

[falken]

Hallo Reinhard,
da kam eine Meldung:
„\server\daten$\Angebote\2\2792_Nagel wurde in ca. ,00sec angelegt.“
Wenn ich dann „OK“ drücke kommt wieder die Fehlermeldung mit der unzulässigen Funktion vom „saveAs“-Befehl.
Freundliche Grüße
Thomas

[Reinhard_fb8cb7]

da kam eine Meldung:
„\server\daten$\Angebote\2\2792_Nagel wurde in ca. ,00sec
angelegt.“
Wenn ich dann „OK“ drücke kommt wieder die Fehlermeldung mit
der unzulässigen Funktion vom „saveAs“-Befehl.

Hallo Thomas,

okay, *schweißabwisch* haben wir ja diesen Punkt geklärt.
lösch die Zeile mit Sleep und die Zeile mit der Msgbox.
Lass die While-Schleife einstweilen noch drin.

Thomas Ramel hat ja auf drei Punkte hingewisen. Die While-Schleife entspricht ja seinem dritten Punkt.
Bleiben noch die beiden anderen, teste jetzt mal den ersten Punkt.

Gruß
Reinhard

[Reinhard_fb8cb7]

Ansonsten kannst Du mit ein klein wenig API und MakePath
prüfen und dafür sorgen, dass die benötigten Ordner jeweils
korrekt angelegt werden.

Grüezi Thomas,

sind die API Funktionen MakePath und ggfs. MakeSureDirectoryPathExists „sicherer“ ?
Jetzt im Vergleich zu MkDir bzw. Dir().

Falls der Dateizugriff „lahmt“ ist dann

MakePath(…)
.Saveas …

sicherer als

MkDir …
.Saveas …

Analog dazu was ist die sichere Variante ggfs. in einer Warteschleife nach der Ordnererzeugung:

in

While MakeSureDirectoryPathExists(…) = False
Wend

oder

While Dir(…) =""
Wend

Und zu FileFormat, Dateiendung angeben, *grübel*
Ist da der sicherere Weg die dateiendung wegzulassen und das mit Fileformat zu tun?

Ist das so eine Art Problematik die nicht ergründbar ist. D.h.
ich bastle mir Code der 10.000 mal so SaveAs Vorgänge durchführt,
und sagen wir mal zufallsgesteuert so 10 Mappen permanent abspeichert,
mal mit Dateiendungsangabe mal ohne, und mal eine Datei herausgegriffen, 497mal hat es mit Angabe der Dateiendung funktioniert aber 112 mal nicht.

Wahrlich ein problem wo ich ein dickes Fragezeichen im Kopf hätte. Naja, hab ich in Excel öfters *lächel*

Wenn es Probleme und Verzögerungen beim Zugriff auf den Server
gibt, dann kann es sein, dass der Ordner noch nicht angelegt
ist, und die SaveAs-Methode bereits speichern will - dann
hilft IMO nichts anderes als Warten und/oder nach dem Anlegen
des Ordners prüfen ob er auch da ist und das in einer Schleife
vor dem SaveAs Befehl.

Der Punkt ist m.E. geklärt, dachte ich auch dran, aber daran liegt es hier wohl nicht.

Gruß
Reinhard

[falken]

9 Schritte
Moin Thomas,
freue mich sehr auch über Dein Interesse an diesem komplizierten Thema mit dem ätzenden Makro

Die Existenz des kompletten korrekten Pfades habe ich aber mehrmals vor dem Auftreten des Fehlers überprüft ( immer parallel zum EinzelSchrittModus mit dem Windows-Explorer ).
Vielleicht einmal ganz akribisch:

1. Löschen des aus vorherigen Versuchen bestehenden ZielOrdners per Explorer
2. Starten des Makros mit Lauf bis zur Stop-Marke
3. DurchChecken des Makros im Einzelschritt
4. im EinzelSchritt die Verzweigung zum UnterProgramm „Ordner erzeugen“
5. Sichtung des neu angelegten Ordners per Explorer
6. weiter im EinzelSchritt samt Rückkehr ins HauptMakro und dort weiter bis zu der Zeile, in der
7. die VorlagenDatei sich selber unter anderem Namen in den neuen Ordner schreiben soll und
8. stattdessen eine der beiden FehlerMeldungen anzeigt, dass es nicht geklappt hat
9. hat dann allerdings die aktive Datei den neuen Namen, aber noch den Pfad der VorlagenDatei

Wenn ich Schritt 1 weglasse, klappt es wie geplant.

Ich glaube, ich habe die Nicht-Existenz des Pfades als mögliche Ursache für den Fehler damit hinreichend ausgeschlossen.

Ich fürchte, ich muss die Tage an einer kleinen Beispiel-Ordnerstruktur basteln und als zip-Datei ins Netz stellen.
Oder hat noch Jemand eine rettende Idee?

API habe ich schon öfters gelesen, aber leider weiß ich nicht wirklich, was das ist.
Statt MakePath habe ich MkDir benutzt. Ist das ein Unterschied?

Freundliche Grüße und Dank für jeden HilfeVersuch
Thomas

[Reinhard_fb8cb7]

Hallo Thomas,

freue mich sehr auch über Dein Interesse an diesem
komplizierten Thema mit dem ätzenden Makro

lassen wir ab jetzt bitte das „ätzend“ weg, es wurde besprochen und gut ist.
Selbst du weißt jetzt schon daß dein Code noch äh gewaltiges Verbesserungspotential hat
Also ist nix gar nix geschehen was von belang ist.

Vielleicht einmal ganz akribisch:

1. Löschen des aus vorherigen Versuchen bestehenden
   ZielOrdners per Explorer

? Du hast möglicherweise Probleme beim Erstellen des Zielordners und löscht ihn sichherheitshalber vor dem Erstellen?

2. Starten des Makros mit Lauf bis zur Stop-Marke
3. DurchChecken des Makros im Einzelschritt
4. im EinzelSchritt die Verzweigung zum UnterProgramm „Ordner
   erzeugen“

Setz doch den Haltepunkt gleich in das UP.
Das meine ich mit F8, F5, Haltepunkt im Wechsel. Ich habe es geschrieben aber irgendwie kommt das was ich schreibe nicht an
Es kommt weder die Nachfrage was ich damit meine noch gehe ich davon aus daß du so Fehler suchst.

5. Sichtung des neu angelegten Ordners per Explorer

(Ich will es jetzt nicht unnötig kompliziert machen aber das Erscheinen eines Ordners oder einer Datei in der Exploreransicht bedeutet nicht daß dieser Ordner, diese Datei frei zugänglich ist.
In deinem Fall daß SaveAS funktioniert.)

6. weiter im EinzelSchritt samt Rückkehr ins HauptMakro und
   dort weiter bis zu der Zeile, in der
7. die VorlagenDatei sich selber unter anderem Namen in den
   neuen Ordner schreiben soll und

Vorlage? Muß ich mal drüber schlafen ob daher Probleme kommen könnten.

8. stattdessen eine der beiden FehlerMeldungen anzeigt, dass
   es nicht geklappt hat
9. hat dann allerdings die aktive Datei den neuen Namen, aber
   noch den Pfad der VorlagenDatei

? Trotz Fehlermeldung hat die Namensänderung die ja nur durch Speichern geht funktioniert?
Verwirrt mich, schlaf ich gleich mit drüber

Gruß
Reinhard

[Thomas_Ramel]

Grüezi Reinhard

Ansonsten kannst Du mit ein klein wenig API und MakePath
prüfen und dafür sorgen, dass die benötigten Ordner jeweils
korrekt angelegt werden.

sind die API Funktionen MakePath und ggfs.
MakeSureDirectoryPathExists „sicherer“ ?
Jetzt im Vergleich zu MkDir bzw. Dir().

Sicherer vermutlich nicht, jedoch in der Lage auch verschachtelte Unterordner in beliebiger ‚Tiefe‘ anzulegen, wenn ein übergeordneter Ordern noch nicht existiert.
MKDIR kann ‚nur‘ eine Ebene tief Ordnder anlegen, für eine Verschachtelung dreifacher Tiefe muss daher mit 3 Durchläufen für je eine Stufe tiefer gearbeitet werden.

Des weiteren ist bei der API-Funktion auch gleich eine Prüfung mit drin - gibts den Ordner schon wird das gemeldet, gibts ihn noch nicht wird er angelegt, alles mit dem gleichen einfachen Code.

Für die Prüfung dürfte es auf dasselbe herauskommen, denke ich.

Und zu FileFormat, Dateiendung angeben, *grübel*
Ist da der sicherere Weg die dateiendung wegzulassen und das
mit Fileformat zu tun?

Aber ja, ganz bestimmt - seit xl2007 ist es sogar die einzig richtige Methode!!
Das war bis xl2003 nicht der Fall. Obschon unsauber programmiert hat es gereicht an den Dateinamen einfach ein „.xls“ anzuhängen, da sowieso standardmässig in diesem Format gespeichert worden ist.
Seit xl2007 gibt es aber für 3 verschiedene Dateiformate, die sich auch in der Struktur der gespeicherten Daten grundlegend unterscheiden. Daher ist es nun (richtigerweise) notwendig, das genaue Dateiformat bei .Save As() angzugeben.

Ist das so eine Art Problematik die nicht ergründbar ist. D.h.
ich bastle mir Code der 10.000 mal so SaveAs Vorgänge
durchführt,
und sagen wir mal zufallsgesteuert so 10 Mappen permanent
abspeichert,
mal mit Dateiendungsangabe mal ohne, und mal eine Datei
herausgegriffen, 497mal hat es mit Angabe der Dateiendung
funktioniert aber 112 mal nicht.

Nein, ich denke das müsste eigentlich zuverlässig klappen.
Ich vermute die Probleme eher Netzwerk- oder Berechtigungs-seitig.

Wenn es Probleme und Verzögerungen beim Zugriff auf den Server
gibt, dann kann es sein, dass der Ordner noch nicht angelegt
ist, und die SaveAs-Methode bereits speichern will - dann
hilft IMO nichts anderes als Warten und/oder nach dem Anlegen
des Ordners prüfen ob er auch da ist und das in einer Schleife
vor dem SaveAs Befehl.

Der Punkt ist m.E. geklärt, dachte ich auch dran, aber daran
liegt es hier wohl nicht.

Nunja - irgend eine Ursache muss das Ganze ja wohl haben.

Ev. hilft es, den Code mal sauber in einer neu erstellten Mappe auf Herz und Nieren zu testen. Wenn nämlich die Mappe selbst korrumpiert ist (das ist oft oder meist der Fall, wenn sich ein bestimmtes Verhalten nicht erklären und ergründen lässt), dann muss die Mappe anschliessend sauber neu aufgebaut werden.

Mit freundlichen Grüssen

Thomas Ramel

• MVP für MS-Excel -

[Thomas_Ramel]

grüezi Thomas

Moin Thomas,
freue mich sehr auch über Dein Interesse an diesem
komplizierten Thema…[…]

Aber immer gerne doch

Die Existenz des kompletten korrekten Pfades habe ich aber
mehrmals vor dem Auftreten des Fehlers überprüft ( immer
parallel zum EinzelSchrittModus mit dem Windows-Explorer ).

Das reicht meiner Ansicht nach so nicht aus - ich würde das im Code drin protokollieren lassen…

Vielleicht einmal ganz akribisch:

1. Löschen des aus vorherigen Versuchen bestehenden
   ZielOrdners per Explorer
2. Starten des Makros mit Lauf bis zur Stop-Marke
3. DurchChecken des Makros im Einzelschritt
4. im EinzelSchritt die Verzweigung zum UnterProgramm „Ordner
   erzeugen“
5. Sichtung des neu angelegten Ordners per Explorer

…denn hier lässt Du dem System genügend Zeit für die Erstellung des Ordners, da Du ja per F8 die Zeilen durchläufst und im Explorer kontrollierst.
In der Dynamik des Ablaufs ohne die Einzelschritte, liegt das sehr viel weniger Zeit zwischen Erzeugung und Verwendung des Ordners.

Daher eben eine Schleife oder Wartezeit um sicherzustellen, dass der Ordner auf dem Server auch angelegt worden ist.
Zentrale Server können je nach Zugriff auch mal ausgelastet und/oder langsamer sein. Je nach Zeitpunkt an dem Du darauf zugreifst kann es also auch mal länger dauern bis der Ordner angelegt ist. Mit dem Makro-Code an sich hat das dann nichts zu tun.

Wenn ich Schritt 1 weglasse, klappt es wie geplant.

…und warum lässt Du dann Schritt 1 nicht einfach weg?

Mit der API-Funtkion würde dies eben geprüft und der Ordner wird nur angelegt wenn er noch nicht existiert.

So gesehen könnte es auch sein, dass der Server dann ein Latenz-Propblem hat, wenn Du den Ordner löschst und dann gleich wieder mit demselben Namen anlegst…

Ich fürchte, ich muss die Tage an einer kleinen
Beispiel-Ordnerstruktur basteln und als zip-Datei ins Netz
stellen.
Oder hat noch Jemand eine rettende Idee?

Prüfe den momentan bestehenden Code mal noch in einer neu erstellten und ansonsten leeren Mappe - ev. ist deine Mappe korrumpiert und reagiert daher seltsam.

API habe ich schon öfters gelesen, aber leider weiß ich nicht
wirklich, was das ist.
Statt MakePath habe ich MkDir benutzt. Ist das ein
Unterschied?

Oh, ja - wie bereits Reinhard erklärt ist MKDIR ‚nur‘ in der Lage Ordner eine Ebene tiefer als die bislang existierenden anzulegen, brauchst Du daher 3 Ebenen tiefer musst Du jeden Ordner einzeln anlegen. Des weiteren benötist Du eine andere Funktion (DIR) um zu prüfen ob ein Ordner bereits exisitert.
Mit der API-Funktion MakePath hast Du alles in einem:
Ein Order in beliebig tiefer Unterstruktur kann in einem Rutsch angelegt werden. Und derselbe Befehl prüft ob der Ordner schon existiert und legt ihn an, falls das nicht der Fall sein sollte.

Das Ganze sieht dann in der Deklaration in einem Modul der Mappe wie folgt aus:

Option Explicit

Declare Function MakePath Lib "imagehlp.dll" Alias \_
 "MakeSureDirectoryPathExists" (ByVal lpPath As String) As Long

Function CreatePath(ByVal strPath As String) As Long
 'Sicherstellen, dass ein abschliessender Backslash vorhanden ist
 If Right(strPath, 1) "\" Then strPath = strPath & "\"
 CreatePath = MakePath(strPath)
End Function

Und aufgerufen wird die Funktion als Beispiel dann so

Sub Test()
 If CreatePath("C:\Test\Test1\Test2\Test3\Test4\") = 0 Then
 MsgBox "Pfad konnte nicht angelegt werden!"
 End If
End Sub

…wobei anstelle der MsgBox eine beliebige Fehler-Behandlung oder eine Do-Loop Schleife stehen kann (das hat aber den Nachteil, dass wenn das Ganze mal über längere Zeit nicht klappt, der Code in einer Endlos-Schleife hängt:

Sub Test()
 Do
 Loop While (CreatePath("C:\Test\Test1\Test2\Test3\Test4\") = 0)
MsgBox "Done"
End Sub

Mit freundlichen Grüssen

Thomas Ramel

• MVP für MS-Excel -

[Reinhard_fb8cb7]

Grüezi Thomas,

sind die API Funktionen MakePath und ggfs.
MakeSureDirectoryPathExists „sicherer“ ?
Jetzt im Vergleich zu MkDir bzw. Dir().

Sicherer vermutlich nicht,

das wollte ich wissen aber „vermutlich“ irritiert mich
Wichtiger Hintergrund ist, im VB-Brett war ich mal als kleines Licht an einer Beitragsfolge beteiligt mit dem Ex-Mod Rainer Fischer und Alex, die dann zur FAQ:3000 von Alex führte.

Ich erinnere mich sehr genau daß Alex im Zuge dieser Beitragsfolge
vor der Benutzung von „Dir“ warnte und dies auch begründete.
Leider habe ich die Begründung vergessen.
Das ist mit der hauptgrund warum ich bei dir nachfragte, vielleicht weißt du da auch was Negatives an Dir.
Okay, ich kontaktiere Alex mal per Mail.

Für die Prüfung dürfte es auf dasselbe herauskommen, denke
ich.

Okay.

Und zu FileFormat, Dateiendung angeben, *grübel*
Ist da der sicherere Weg die dateiendung wegzulassen und das
mit Fileformat zu tun?

Aber ja, ganz bestimmt - seit xl2007 ist es sogar die einzig
richtige Methode!!

Danke, werde mich daran halten ab jetzt.

Seit xl2007 gibt es aber für 3 verschiedene Dateiformate, die
sich auch in der Struktur der gespeicherten Daten grundlegend
unterscheiden. Daher ist es nun (richtigerweise) notwendig,
das genaue Dateiformat bei .Save As() angzugeben.

Die Liste der zulässigen FileFormat-Werte in F1 von XL 2007 ist recht lang. Manches ist mir noch nicht einleuchtend. Aber kann so bleiben.
Zur Not zeichne ich ein Makro auf.

Ich vermute die Probleme eher Netzwerk- oder
Berechtigungs-seitig.

Ich habe kein Netzwerk aber müßte bei fehlender Berechtigung nicht schon die Fehlermeldung bei MkDir kommen und nicht erst bei SaveAs?

Der Punkt ist m.E. geklärt, dachte ich auch dran, aber daran
liegt es hier wohl nicht.

Nunja - irgend eine Ursache muss das Ganze ja wohl haben.

Jepp. Ob man die Ursache aus der Ferne aufklären kann ist für mich derzeit fraglich. Stephan erzählt ja auch von seltsamen, sporadischen Überraschungen.
Problem ist sowas nachzustellen
Ich liebe statische feste Fehler )

Gruß
Reinhard

[Thomas_Ramel]

Grüezi Reinhard

sind die API Funktionen MakePath und ggfs.
MakeSureDirectoryPathExists „sicherer“ ?
Jetzt im Vergleich zu MkDir bzw. Dir().

Sicherer vermutlich nicht,

das wollte ich wissen aber „vermutlich“ irritiert mich

Das steht da nur weil ich das Ganze nicht intensiv quergetestet habe und die Aussage so daher meine Ansicht wiedergibt.

Wichtiger Hintergrund ist, im VB-Brett war ich mal als kleines
Licht an einer Beitragsfolge beteiligt mit dem Ex-Mod Rainer
Fischer und Alex, die dann zur FAQ:3000 von Alex führte.

Ich erinnere mich sehr genau daß Alex im Zuge dieser
Beitragsfolge
vor der Benutzung von „Dir“ warnte und dies auch begründete.
Leider habe ich die Begründung vergessen.
Das ist mit der hauptgrund warum ich bei dir nachfragte,
vielleicht weißt du da auch was Negatives an Dir.

Nein, mir fällt da spontan nichts ein.

Ich vermute die Probleme eher Netzwerk- oder
Berechtigungs-seitig.

Ich habe kein Netzwerk aber müßte bei fehlender Berechtigung
nicht schon die Fehlermeldung bei MkDir kommen und nicht erst
bei SaveAs?

Nicht zwingend - wenn da ein Ordner in einer übergeordneten Stufe fehlt geht MkDir IMO einfach weiter und legt dann halt die Ordner nicht an - eine Meldung gibt es da nicht,
Ganz im Gegensatz zur vorgestellten API-Methode.

Ich liebe statische feste Fehler )

Ja, speziell wenn ich diese dann auch noch selbst eingebaut habe…

Mit freundlichen Grüssen

Thomas Ramel

• MVP für MS-Excel -

[falken]

Hallo Reinhard,
nimm´s bitte nicht persönlich, wenn ich nicht immer sofort antworten kann. Bin auch etwas unsicher, welche Deiner/Eurer Tips jetzt auf welchen Annahmen beruhen. Muss ich mir morgen ´mal genauer ansehen und sortieren.
Gute Nacht
Thomas

[falken]

Guten Abend Thomas,
danke für Deine Antwort.

grüezi Thomas

Moin Thomas,
freue mich sehr auch über Dein Interesse an diesem
komplizierten Thema…[…]

Aber immer gerne doch

Die Existenz des kompletten korrekten Pfades habe ich aber
mehrmals vor dem Auftreten des Fehlers überprüft ( immer
parallel zum EinzelSchrittModus mit dem Windows-Explorer ).

Das reicht meiner Ansicht nach so nicht aus - ich würde das im
Code drin protokollieren lassen…

Vielleicht einmal ganz akribisch:

1. Löschen des aus vorherigen Versuchen bestehenden
   ZielOrdners per Explorer
2. Starten des Makros mit Lauf bis zur Stop-Marke
3. DurchChecken des Makros im Einzelschritt
4. im EinzelSchritt die Verzweigung zum UnterProgramm „Ordner
   erzeugen“
5. Sichtung des neu angelegten Ordners per Explorer

…denn hier lässt Du dem System genügend Zeit für die
Erstellung des Ordners, da Du ja per F8 die Zeilen durchläufst
und im Explorer kontrollierst.

Eben. Das mache ich ganz bewusst so langsam. Und der Fehler kommt trotzdem ( zudem noch mit 2 verschiedenen Texten ). Deshalb denke ich, dass man die Dynamik zunächst außen vor lassen kann.
Solange der Code langsam nicht läuft muss ich mir doch keine Gedanken über den schnellen DurchLauf machen. Der wird dann erst recht nicht zum gewünschten Ergebnis führen. Da weiß ich dann auch nicht, ob eine Protokollierung weitere Erkenntnisse bringt.

In der Dynamik des Ablaufs ohne die Einzelschritte, liegt das
sehr viel weniger Zeit zwischen Erzeugung und Verwendung des
Ordners.

… Mit dem Makro-Code an sich hat das dann nichts
zu tun.

Sehe ich auch so. Wohl eher ein Bug, wenn MSExcel den Ordner nicht sieht, den es selber angelegt hat und der im MSExplorer angezeigt wird.

Wenn ich Schritt 1 weglasse, klappt es wie geplant.

…und warum lässt Du dann Schritt 1 nicht einfach weg?

@ Reinhard: Darüber hatten wir anfangs schon gesprochen … „Plan B“.

Mit der API-Funtkion würde dies eben geprüft und der Ordner
wird nur angelegt wenn er noch nicht existiert.

So gesehen könnte es auch sein, dass der Server dann ein
Latenz-Propblem hat, wenn Du den Ordner löschst und dann
gleich wieder mit demselben Namen anlegst…

Den Ordner lösche ich manuell, damit der Fehler auftritt. Und ich erwähne es nur, um zu zeigen, dass der Fehler nur bei frisch angelegtem Ordner auftritt.

Ich fürchte, ich muss die Tage an einer kleinen
Beispiel-Ordnerstruktur basteln und als zip-Datei ins Netz
stellen.
Oder hat noch Jemand eine rettende Idee?

Prüfe den momentan bestehenden Code mal noch in einer neu
erstellten und ansonsten leeren Mappe - ev. ist deine Mappe
korrumpiert und reagiert daher seltsam.

API habe ich schon öfters gelesen, aber leider weiß ich nicht
wirklich, was das ist.
Statt MakePath habe ich MkDir benutzt. Ist das ein
Unterschied?

Oh, ja - wie bereits Reinhard erklärt ist MKDIR ‚nur‘ in der
Lage Ordner eine Ebene tiefer als die bislang existierenden
anzulegen, brauchst Du daher 3 Ebenen tiefer musst Du jeden
Ordner einzeln anlegen.

Ich muss in diesem Fall aber nur eine OrdnerEbene neu erstellen und das klappt auch sehr gut. Beim zweiten DurchLauf schreibt sich die Datei ja genau dort hinein.

Des weiteren benötist Du eine andere
Funktion (DIR) um zu prüfen ob ein Ordner bereits exisitert.

Ist im Code vorhanden und funktioniert.

Mit der API-Funktion MakePath hast Du alles in einem:
Ein Order in beliebig tiefer Unterstruktur kann in einem
Rutsch angelegt werden. Und derselbe Befehl prüft ob der
Ordner schon existiert und legt ihn an, falls das nicht der
Fall sein sollte.

Und wenn er schon existiert ist das auch o.k.? Dann ist MakePath wohl tatsächlich komfortabler als MkDir.

Das Ganze sieht dann in der Deklaration in einem Modul der
Mappe wie folgt aus:

Option Explicit

Declare Function MakePath Lib „imagehlp.dll“ Alias _
„MakeSureDirectoryPathExists“ (ByVal lpPath As String) As Long

Function CreatePath(ByVal strPath As String) As Long
'Sicherstellen, dass ein abschliessender Backslash vorhanden
ist
If Right(strPath, 1) „“ Then strPath = strPath & „“
CreatePath = MakePath(strPath)
End Function

Und aufgerufen wird die Funktion als Beispiel dann so

Sub Test()
If CreatePath(„C:\Test\Test1\Test2\Test3\Test4“) = 0 Then
MsgBox „Pfad konnte nicht angelegt werden!“
End If
End Sub

…wobei anstelle der MsgBox eine beliebige Fehler-Behandlung
oder eine Do-Loop Schleife stehen kann (das hat aber den
Nachteil, dass wenn das Ganze mal über längere Zeit nicht
klappt, der Code in einer Endlos-Schleife hängt:

Sub Test()
Do
Loop While (CreatePath(„C:\Test\Test1\Test2\Test3\Test4“) =
0)
MsgBox „Done“
End Sub

Das werde ich morgen im Büro ausprobieren.
Vielen Dank, Thomas

Mit freundlichen Grüssen

Thomas Ramel

• MVP für MS-Excel -

Bis dahin gute Nacht
Thomas

[falken]

kurz und bündig
kurz und bündig
( Autor: falken (Mitglied seit: 23.9.2008) / Datum: 13.11.2011 18:13 Uhr / Geklickt: 4 mal )

Guten Abend zusammen,
nach einem kurzen RenovierungsWE freue ich mich über zahlreiche Gedanken zu meinem Problem. Jedoch scheint die Diskussion noch weiter abgedriftet zu sein…
Deshalb noch einmal hier das Wesentliche in Kürze, damit es Keiner übersieht.
Die Folgenden Zeilen hatte ich bereits unter „9 Schritte“ an Thomas Ramel geschrieben und sollten verdeutlichen, dass der Fehler auch im EinzelschrittModus auftaucht :

Die Existenz des kompletten korrekten Pfades habe ich aber mehrmals vor dem Auftreten des Fehlers überprüft ( immer parallel zum EinzelSchrittModus mit dem Windows-Explorer ).
Vielleicht einmal ganz akribisch:

1. Löschen des aus vorherigen Versuchen bestehenden ZielOrdners per Explorer
2. Starten des Makros mit Lauf bis zur Stop-Marke
3. DurchChecken des Makros im Einzelschritt
4. im EinzelSchritt die Verzweigung zum UnterProgramm „Ordner erzeugen“
5. Sichtung des neu angelegten Ordners per Explorer
6. weiter im EinzelSchritt samt Rückkehr ins HauptMakro und dort weiter bis zu der Zeile, in der
7. die VorlagenDatei sich selber unter anderem Namen in den neuen Ordner schreiben soll und
8. stattdessen eine der beiden FehlerMeldungen anzeigt, dass es nicht geklappt hat
9. hat dann allerdings die aktive Datei den neuen Namen, aber noch den Pfad der VorlagenDatei

Wenn ich Schritt 1 weglasse, klappt es wie geplant.

Ich glaube, ich habe die Nicht-Existenz des Pfades als mögliche Ursache für den Fehler damit hinreichend ausgeschlossen.

Freundliche Grüße
Thomas

[Thomas_Ramel]

Grüezi Thomas

Die Existenz des kompletten korrekten Pfades habe ich aber
mehrmals vor dem Auftreten des Fehlers überprüft ( immer
parallel zum EinzelSchrittModus mit dem Windows-Explorer ).

Das reicht meiner Ansicht nach so nicht aus - ich würde das im
Code drin protokollieren lassen…

Sehe ich auch so. Wohl eher ein Bug, wenn MSExcel den Ordner
nicht sieht, den es selber angelegt hat und der im MSExplorer
angezeigt wird.

Wenn ich Schritt 1 weglasse, klappt es wie geplant.

…und warum lässt Du dann Schritt 1 nicht einfach weg?

@ Reinhard: Darüber hatten wir anfangs schon gesprochen …
„Plan B“.

…ich kann nicht nachvollziehen was Du da mit Reinhard besprochen hat, also lasse ich das mal so stehen…

Mit der API-Funtkion würde dies eben geprüft und der Ordner
wird nur angelegt wenn er noch nicht existiert.

So gesehen könnte es auch sein, dass der Server dann ein
Latenz-Propblem hat, wenn Du den Ordner löschst und dann
gleich wieder mit demselben Namen anlegst…

Den Ordner lösche ich manuell, damit der Fehler auftritt. Und
ich erwähne es nur, um zu zeigen, dass der Fehler nur bei
frisch angelegtem Ordner auftritt.

Hmmm, das ging aus deiner Schilderung für mich nicht so klar hervor, aber gut, dass der Punkt geklärt ist.

Hast Du schon mal versucht, den Code isoliert in einer neu angelegten Mappe zu prüfen?
Passiert da dasselbe ebenfalls?

Wenn ja solltest Du die Mappe dringend neu aufbauen.

Und wenn er schon existiert ist das auch o.k.? Dann ist
MakePath wohl tatsächlich komfortabler als MkDir.

Ja, das sehe ich definitiv so.

Mit freundlichen Grüssen

Thomas Ramel

• MVP für MS-Excel -

[Stephan_8a4919]

Hallo Thomas,

Wenn ich Schritt 1 weglasse, klappt es wie geplant.

schon seltsam. (Ob es etwas damit zu tun hat, dass bei nicht Vorhandensein des Ordners in eine andere Prozedur gegangen wird?)

Ich glaube, ich habe die Nicht-Existenz des Pfades als
mögliche Ursache für den Fehler damit hinreichend
ausgeschlossen.

Ja, das sehe ich auch so.

Falls noch nicht geschehen würde ich jetzt versuchen:

(1)
Den Speichernamen (also Pfad\Dateiname.xls) zunächst in einer Variable zusammenfassen und im SaveAs Befehl diese Variable für FileName benutzen. Per Msgbox lasse ich mir dann, bevor der Befehl SaveAs ausgeführt wird, anzeigen, was genau in der Variablen steht. Ich halte es nach wie vor für zwar unwahrscheinlich aber nicht unmöglich, dass hier etwas nicht stimmt. (/t/datei-speichern-in-neues-verzeichnis/6671463/25

(2)
Wenn (1) zu keinen neuen Erkenntnissen führt, würde ich den Code so umschreiben, dass alle benutzten Pfade und Dateien auf meinem lokalen PC verweisen bzw. liegen. Es muss ausgeschlossen werden, dass irgendwelche Berechtigungen oder Sicherheitseinstellungen einen Strich durch die Rechnung machen.

Viel Erfolg!

MfG
Stephan