2015-05-29 7 views
37

Ich habe ein Python-Skript, das auf meinem Entwicklungs-PC einwandfrei funktioniert. Beide sind Windows   7 mit der gleichen Python-Version (2.7.9). Doch auf der Zielmaschine bekomme ich eineFehler "ValueError: kann Daten nicht so früh formatieren" auf einem PC, funktioniert auf anderen

ValueError: can't format dates this early

The error von pywin32 Modul zu kommen scheint.

Der Code verwendet eine Drittanbieter-Bibliothek von pywin32 aufgerufen:

raw = win32com.client.Dispatch("MyLib.MyClass") 

und versagt dann später:

acq_time = raw.GetCreationDate() 

Jetzt bin ich verloren, warum dies auf meinem PC arbeitet und nicht auf der Zielmaschine. Beide haben eine "corporate install" von Windows   7, zum Beispiel die gleichen Regions- und Datum-Uhrzeit-Einstellungen.

Was ist das Problem? Wie kann ich es lösen?

EDIT:

Siehe Kommentare. Die Ursache ist wahrscheinlich, welche C++ Laufzeit verwendet wird. Ich untersuche immer noch. Ich vermute jetzt, dass es wichtig ist, welche Laufzeiten zur Installationszeit von pywin32 vorhanden sind. Warum? Weil DependenyWalker auf meinem Entwicklungs-PC sagt, dass pywin von MSVCR90.DLL in meiner Lotus Notes-Installation abhängt. Das sagt mir, dass es sicher nicht "hart" verlinkt ist.

-Update 30.06.2015:

ich alles falsch war ... Das Problem jetzt geschieht auch auf meinem PC.

Einige weitere Informationen. Das Skript liest Datendateien und fügt die gelesenen Metadaten in eine Datenbank ein. Nur ältere Dateien schienen vom Bug betroffen zu sein, nicht neue (ich glaube jetzt, das ist die Annahme falsch). Also die Idee war es zunächst auf meinen Dev-PC zu laden und dann hoffe das Problem bei neuen Dateien nie wieder auftauchen zu können.

Bei einem PC, auf dem das Skript ausgeführt wird, befinden sich die gelesenen Dateien auf einem freigegebenen Windows-Laufwerk (zugeordnetes Netzlaufwerk). Ich habe keinen Zugriff auf dieses Laufwerk , also habe ich nur die Dateien auf meinen PC kopiert. Jetzt für die erste Last Ich habe Zugriff auf besagte Netzlaufwerk und BOOM angefordert. Es funktioniert auch nicht Arbeit von meinem Dev. Maschine beim Lesen vom freigegebenen Laufwerk.

Das Problem tritt nicht immer mit der gleichen Datei auf. Ich denke jetzt, dass es nichts mit einer bestimmten Datei zu tun hat. Ich habe es auch auf einem 64-Bit-PC mit 64-Bit-Python versucht. Dort dauerte es länger bis der Fehler auftrat. Tatsächlich wurde eine Datei erfolgreich gelesen, die auf meinem PC fehlschlug. Ich denke jetzt, es ist eine Art von Gedächtnisproblem? Ich glaube, dass es dann immer an der Datumsgrenze scheitert, weil alle anderen Zeilen nur null oder eine leere Zeichenfolge zurückgeben, die kein Problem verursacht und durchaus möglich ist, dass ein solcher Wert null sein kann. Aber für das Datum ist es ein Problem und es sollte nicht Null sein und dann wird der Fehler ausgelöst.

EDIT von Update:

Auf meinem PC es nicht immer auf der gleichen Datei. Das Laden dieser Datei allein funktioniert einwandfrei. Ich denke jetzt, dass es eine Art Zähler-/Nummernüberlauf ist, dass nach dem Lesen von n-Dateien das Problem auftritt.Es hat mit der Menge der Dateien zu tun, die ich pro Lauf des Skripts lade und nicht die Datei selbst. Dateien, die fehlschlagen, funktionieren, wenn sie einzeln geladen werden.

+2

Gleiche Version von 'pywin32' auf beiden Maschinen? Die gleiche Version der Bibliothek? –

+0

Der verlinkte Kommentar von Mark Hammond sagt, '_tcsftime versucht," hilfreich "zu sein, indem er mit einem zu frühen Datum in einigen CRT-Implementierungen stirbt (zB vs2008 64bit - und wahrscheinlich andere). Welche CRT benutzen Sie? –

+1

Was ist mit den Windows-Ländereinstellungen, insbesondere dem Datumsformat? –

Antwort

1

Es stellte sich heraus, das Problem war in der Tat trivial und etwas aufgrund meiner mangelnden Erfahrung mit Python und irreführende Fehlermeldung.

Das COM-Objekt raw = win32com.client.Dispatch("MyLib.MyClass") wird verwendet, um proprietäre Dateien in einer Schleife zu öffnen. Um das Problem zu lösen, muss das Objekt vor der nächsten Iteration "aufgeräumt" werden. Dies erfolgt entweder durch

del raw oder raw = None.

Das löst das Problem vollständig. Es hat absolut nichts mit Daten oder Datumsformatierung zu tun. Also hat Peter Brittain vermutlich recht, dass dieses Dateilimit erreicht wurde.

Verwandte Themen