Mahnstapel Access (Version 9.0)

Bisut

Aktives Mitglied
Hallo Forum Helfer,

ich habe einen Endkunden von Version 8.1 auf 9.0 gebracht. Die Server sind dabei alle gleich geblieben. Die Sage erstellt jetzt aber keine Mahnstapel mehr. Der Sage Support ist hier wohl irgendwie auch nicht wirklich hilfreich. Zumindest gab es bisher hier keine guten Lösungsvorschläge als sonst (nach dem Motto, Sage neu installieren).

Es scheint irgendwie an dem Access zu liegen. Die Speicher Erweiterung über OL Admin (Aus oder An) bringt nichts. Aus dem Trace Log dazu werde ich nicht schlau. (Siehe bitte Anlage Bild Dateien). An der Datenbank kann es aber nicht liegen, die habe ich schon testweise geholt und probiert. Und läuft einwandfrei.

Beim Erstellen des Mahnstapel kommt es zu keinem Request, so das hier einfach das Fenster sich einfriert und nichts tut. Access geht dann solange auf "Inaktiv", und nur dann wenn man diesen Task manuell beenden möchte und dann die Abfrage kommt, ob Access beendet werden soll, oder auf "Programm warten" geht. Also man muss dann auf "Programm warten" gehen, dann kommt die Erstellung des Stapels.

Ich bin ja kein Freund dieser Access Politik. Auf dem Client (ist in dem Fall ein Windows Terminal Server 2016) gibt es neben dem Access Runtime 2016 auch noch das Access Runtime 2013 (das von der 8.1 Version); diese muss aber noch bleiben, weil der Kunde neben der Sage Rewe noch das Sage HR hat und die benötigen noch das alte Access. Auf dem Server selber gibt es kein Access 2013 nur die 2016 Version, aber auch dort gibt es die gleichen Probleme. An den Usern kann es auch nicht liegen. Habe ich schon alle durch.

Wer hat hier eine gute Idee?

Gruß
 

Anhänge

  • WTS_Arbeitsspeicher.JPG
    WTS_Arbeitsspeicher.JPG
    54,6 KB · Aufrufe: 13
  • WTS_Task.JPG
    WTS_Task.JPG
    32,2 KB · Aufrufe: 13
  • Mahnstapel.jpg
    Mahnstapel.jpg
    647,9 KB · Aufrufe: 15
Ach so, die Neuprüfung auf LiveUpate wurde auch schon auf Anraten von Sage gemacht, aber auch ohne Erfolg.
 
Auf Terminalservern sind verschiedene Office-Versionen explizit nicht freigegeben. Die Sage HR funktioniert mit Access 2013 - 2019. Der Pfad zur gewünschten Access-Version kann im HR-Administrator eingestellt werden.
 
@m.becker (Welche Office Versionen nicht?), eine Liste Ich kenne mich mit HR nicht aus, aber meine Kollegen meinen, das wegen bestimmte Bescheinigungen hier immer Probleme gibt, wenn man das in der HR auf 2016 oder 2019 umstellt.
 
Aber in dem Momement bedient sich die Sage noch gar nicht beim Erstellen auf die Dienste von der MS Office Version. Sondern doch dann nur, wenn man den Export auf "per Mail" machen würde. Also müste doch der Stapel dennoch erstellt werden?
 
Für einen Lösungsansatz wäre gut zu wissen, was denn der Client noch macht und was nicht.

Kommt das Selektionsfenster?
Kommt nach OK das "Erstelle Mahnstapel"-Fenster?
Oder was passiert denn überhaupt genau?
 
Bis auf den Druck der Mahnungen ist fast alles im Mahn-Prozess noch in Access umgesetzt.

@m.becker (Welche Office Versionen nicht?), eine Liste Ich kenne mich mit HR nicht aus, aber meine Kollegen meinen, das wegen bestimmte Bescheinigungen hier immer Probleme gibt, wenn man das in der HR auf 2016 oder 2019 umstellt.
Auf Terminalservern sind gar keine unterschiedlichen Office-Versionen freigegeben, egal welche Versionen. Also bspw. kein 2013 und 2016 gleichzeitig. Probleme mit Access 2016/2019 im HR kann ich von unserer eigenen Installation und von Kunden nicht bestätigen.
 
Auf dem Client (ist in dem Fall ein Windows Terminal Server 2016) gibt es neben dem Access Runtime 2016 auch noch das Access Runtime 2013 (das von der 8.1 Version); diese muss aber noch bleiben, weil der Kunde neben der Sage Rewe noch das Sage HR hat und die benötigen noch das alte Access.
Das steht im ursprüngliche Post anders. Die Runtime ist auch Office.
 
@KMoeser
Es läuft erstmal alles ganz normal. Selektionsfenster kommt und dann eben nach dem OK kommt nicht das Fenster welches die Erstellung des Mahnstapels machen würde. Sieht dann so aus:
Mahnstapel_Auf_Antwort_warten.jpg
Und schaut man sich dann den Task an:
WTS_Task.JPG
Und schaut man sich dann Arbeitsspeicher an:
WTS_Arbeitsspeicher.JPG
Diese "Inaktivität des MS Access" bleibt die ganze Zeit bestehen. Auch im Trace Log passiert in dem Moment gar nichts. Erst wenn man den Task von MS Access beenden möchte, dann aber nicht bendet, sondern bei der Abfrage dann sagt: Auf Programm warten, dann kommt der Request auf die Sage. Dann kommt das Fenster wo die Kunden im Mahnlauf sind. Also der Stapel. Aber eben nur dann. Das ist für den Anwender einfach eine untragbare Situation. Auf dem Server passiert ebenfalls das gleiche. Das ganze kann ich persönlich nicht nachvollziehen. Auch andere Kunden haben dieses Problem nicht, da habe ich auch genügend andere Kunden die auf Terminal Server arbeiten und dort ebenfalls ein MS Office 365 einsetzen. Ich werde mit dem Admin am Donnerstag dort über das MS Removal Tool die bestehenden MS Office Pakete alle deinstallieren (löschen) und dann nur das reine MS Office Access 365 in 32 Bit, welches man für Terminal Server im Paket herunterladen kann, installieren und dann wollen wir uns das Verhalten erneut ansehen. Alternativ würde ich erstmal bei dem Kunden die Sage noch zusätzlich auf einen Client installieren (obwohl das bei dem Kunden nicht gewünscht wäre); aber zu Mindest das Verhalten mir noch mal dort ansehen.

Von einer kompletten Deinstallation der Sage selber halte ich nichts, wiel nach meiner Meinung das nur an dem MS Access liegen kann.

Ich kann nur so viel Bestätigen, das auf WTS die Problematik bezüglich Access höher einzustufen ist als auf den Client. Denn genau dieses Verhalten haben wir auch bei anderen Endkunden mit WTS - allerdings hier nicht in dem Bereich Mahnstapel sodern in dem Bereich Bilanz/BWA/GuV, dort verhält sich die Sage genauso.
 
Das klingt für mich aber eher nach eiinen Daten- oder Einstellugnsproblem.

Bestimmt haben Sie mal die Datenbank in eine andere Installation kopiert bzw. dort den Mahnstapel im Demomandanten laufen lassen, oder?
 
@KMoeser = Ja die DB des Kunden ist OK. Das ist daher kein Datenproblem.

Aber bei dem Demomandaten ist das auch das gleiche Problem beim Kunden.

Wie gesagt, in der 8.1 Version mit allen gleichen Komponenten (Ausnahme das Access) lief das ja alles problemlos. Ich werde das am Donnerstag dann mit dem Admin so erstmal machen, wie bereits beschrieben. Ich vermute einfach das wie bereits von @m.becker erwänt das irgendwie doch mit MS Office Paket zu tun hätte. Obwohl das das gleiche Paket ist, wie in der 8.1 Version.
 
Wir haben bei uns einen ähnlichen Fehler mit der Access 2013 Runtime auf einem Win 2012R2 Terminalserver. Wie von @Bisut beschrieben, bleibt das Access auch wenn Sage (V. 8.1) geschlossen wird inaktiv. Ein direktes wiederöffnen ist nicht möglich , in der Ereignisanzeige bekommen wir dann einen Appliction Hang der MSACCESS.EXE. Wir haben auch schon die Runtime komplett entfernt und wieder neu installiert, jedoch ohne merklichen Erfolg. Wir haben das Problem aber nur auf diesem Server, auf anderen Servern läuft die gleiche Runtime und ich kann das Sage auf und zumachen wie ich will, da gibts keinen Freez des MSACCESS
 
Wir haben nach 6 Stunden Arbeit aufgegeben :mad:

Wir können zumindest so viel sagen: Am Arbeitsspeicher liegt es nicht, An der Sage Installation liegt es nicht, an bestehende MS Office Pakete liegt es auch nicht. An MS Access liegt es nicht.

Das haben wir heute alles feinsauber durchexperimentiert. In der Demo Datenbank funktioniert es jetzt wieder. Daher war unsere Vermutung halt die DB des Kunden, obwohl die hier auf drei unterschiedlichen Testsystemen reibungslos laufen.

Wir konnten nur ein zeitweisen Erfolg verbuchen. Nämlich über OL Admin neue DB erstellt und dann die Funktion Vollständige Daten übernommen (ist dann also keine Kopie) und in dieser neuen DB dann den Druckprozess für Mahnungen neu hinterlegt. Danach ging einmalig der Mahnstapel. Geht man aber neu rein und will den Stapel überschreiben - funktioniert es wieder nicht. Die gleichen Prozesse haben wir bei uns auf drei Systemen gemacht und da war das alles kein Problem.

Am Montag werden wir den jetzigen Stapel erstmal drucken (auch wenn hier dann das Tagesdatum von heute drauf ist); denn ein Überschreiben mit neuem Datum funktioniert ja leider nicht. Wir haben auch probiert nur einen Kunden in den Mahnstapel zu bekommen, aber da bricht die Sage genauso ab.

Bei Sage ist Ticket das dritte mal wieder geöffnet worden, weil alle bisherigen Maßnahmen eben nicht zum Erfolg führen.
 
Der Fall ist noch offen, wir vermuten hier die Virtualisierungen. Die läuft auf einer VM Version 6.7.0 (Build 8169922); hat jemand Erfahrung mit VM? Gibt es dort Einstellungen, die das Verhalten der Sage hier beinflusst. In der VM haben wir eine neue Maschine eingerichtet (also ganz frisch) und die Sage installiert inklusive des SQL Express in der Version 2019 und auch dort war das Verhalten in der Sage gleich.
 
Die Built ist die erste von der 6.7 Version aus 2018.
Seither sind 17 Updates für die 6.7 erschienen.
Wenn es die VM sein soll würd ich den esx mal auf eine aktuelle 6.7 Version heben.
Die aktuelle 6.7 Version ist die 6.7 U3M (Built 17713310) sollte ja relativ einfach aktualisiert werden können. Und auch die Sicherheitsupdates sind dann auf dem aktuellem Stand.
 
@Manuel Goldschmidt = Vielen Dank. Wir werden die VM Updaten! Allerdings erst Anfang Mai.

Ferner haben wir nun eine neue virtuelle Maschine eingerichtet und dort heute einen Testlauf gestartet. Der recht gut aussah. Dennoch wird das Update der VM vorgenommen. Im Testlauf war für fast alle DB die wir eingebunden hatten, der Mahnstapel in Sekunden da. Wenn wir dann aber die Original DB des Kunden genommen haben, war der Mahnstapel erst in 5 Minuten da. Aber es gab jetzt keine Abbrüche mehr, wie vorher. Irgendwie hat die DB des Kunden was, was ungewöhnlich ist. Hersteller Sage prüft aber die DB - nur so wie wir - und wenn wir diese DB nehmen, dann ist der Mahnstapel auch in wenigen Sekunden da. Nur beim Echtbetrieb nicht. Das ganze ist äußerst suspekt. Wir können den Fall wohl jetzt abschließen.

Es lag nicht an der Installation und auch nicht am Access selbst!
 
VM.png So ist die VM eingestellt (Auszug vom EDV Betreuer)

@Manuel Goldschmidt = Die DB ist 1,5 GB groß. Die Test Datenbanken waren zwar kleiner, aber im Mahnstapel war praktisch fast identischer Anzahl von OP drin.
 
Und wieviele VM's laufen auf dem Host?
Was hat der Host an RAM (komplett)?

Ob Ihr einen Wartungsplan über die db laufen lasst braucht ich nicht fragen... (Indizies, Reorganisation und Co.)
 
Zurück
Oben