Hallo zusammen,
ich suche nach Erfahrungsaustausch.
Wir betreiben zahlreiche Access-Anwendungen per Windows Server 2012-Job (Aufgabenplanung).
Im Wesentlichen wir ein Frontend mit eingebundenen Tabellen geöffnet und Code darin abgearbeitet.
Der Code dient überwiegend dem Abfragen von Daten, die werden dann in Excel abgelegt, es gibt aber auch Operationen mit UPDATE usw.
Nun beobachtet sich manchmal, dass ein solches Access-Frontend "offen" bleibt, genauer: die Access-Applikation ist im Taskmanager mit 0% CPU-Last noch aktiv und eine .ldb ist offen. Manchmal sammeln sich die "offenen" auch.
Es sind meistens die selben Anwendungen, bei denen das passiert, andere laufen scheints problemlos. Die Datenhaltung ist auch in mehreren Access-Datenbanken realisiert, d.h. pro Job öffnen sich mehr als eine Access-Datei.
Kennt jemand die Ursache dafür?
Ich habe bei Microsoft nachgelesen, dass Automatisierung bei Access nicht empfohlen wird. Ja, so einfach kann man sichs machen!
Ich habe schon unterschiedliche Dateiformate von Access versucht und auch versucht ein Startscript vorzuschalten. Das Problem scheint aber nicht irgendwo in der Datei zu liegen. Für mich sieht es so aus, als dass die Kommunikation zwischen Task-Planer und Access (Applikation) schlichtweg nicht richtig funktioniert.
Idee war bisher: Eine .Exe zu bauen, dass dann wiederum das Fronend öffnet und Dinge tut. Über .Net-Framework stehen ja di eAccess-Libs zur Verfügung. Zwischen .Exe und Access sollte die Kommunikation ja stimmig sein.
Eine andere Idee wäre den Taskplaner auszutauschen, gibt es da bessere Alternativen?
Datenhaltung in echter DB, aber mit der Idee stehe ich leider alleine da.
Dankeschön
ZitatFür mich sieht es so aus, als dass die Kommunikation zwischen Task-Planer und Access (Applikation) schlichtweg nicht richtig funktioniert.
Der Task-Planer soll separat das Frontend schließen?
ZitatApplikation bleibt offen
Ist denn wirklich sichergestellt, dass alle Zugriffe beendet und alle Objekte ordentlich geschlossen wurden?
Zwischen Funktionieren und sauberem Arbeiten gibt es durchaus Unterschiede, wie sich desweilen zeigt.
ZitatIch habe bei Microsoft nachgelesen, dass Automatisierung bei Access nicht empfohlen wird.
Schlimmer noch: Wenn man sie nicht korrekt anwendet, sollte man generell darauf verzichten.
ZitatDatenhaltung in echter DB, aber mit der Idee stehe ich leider alleine da.
Man sollte aber schon unterscheiden zwischen Frontend- und Backend-Funktionalität.
ZitatAbfragen von Daten, die werden dann in Excel abgelegt, es gibt aber auch Operationen mit UPDATE usw.
Für diese "Funktionalität" kann man auch ganz auf Access verzichten, wenn das das Problem sein soll.
Zitat von: ebs17 am Oktober 16, 2019, 10:56:21
ZitatFür mich sieht es so aus, als dass die Kommunikation zwischen Task-Planer und Access (Applikation) schlichtweg nicht richtig funktioniert.
Der Task-Planer soll separat das Frontend schließen?
Das Frontend schließt sich selbst am ende
Zu den restlichen Posts: Wir wissen was wir tun, zumindest hoffe ich das ;D
Ich werde mal eine Protokolldatei mitlaufen lassen, vielleicht kann man einen "Hänger" identifizieren.
ZitatDas Frontend schließt sich selbst am ende
Welche Kommunikation erwartest Du zwischen Task-Planer und DB-Anwendung außer dem schlichten Starten?
Da muss mehr sein, denn der Verlauf zeigt, dass der Planer (wenn er richtig läuft) so lange läuft bis Access beendet wurde, dann erst wird die Aufgabe beendet.
Hallo,
ZitatKennt jemand die Ursache dafür?
Eher nein...
Vermutungen gibt es aber schon:
Gibt es zeitliche Überlappungen bei der Programmausführung?
Werden die Access-Instanzen sauber beendet? (Taskmanager nachsehen!)
Sind die Anwendungen komplett durchkompiliert und die (alle) Module mit "Option Explicit" versehen?
Gibt es sonstige Kommunikation mit anderen Programmen, die evtl. hängen könnten? ("...Abfragen von Daten, die werden dann in Excel abgelegt...")
Der Taskplaner ist nicht "schuld", der erhält den Status "Bereit" dann, wenn die gestartete Instanz geschlossen, bzw. gekillt wurde.
Der Taskplaner kann auch selber die Instanz killen, bzw. wieder auf "bereit" gehen., wenn er entspr. eingestellt ist.