JTL-Abstürze bei Verbindungsabbruch

[intrinsicforce]

Ist es tatsächlich unmöglich, eine Software zu programmieren, die mit Verbindungsabbrüchen gut umgehen kann?

Simples Beispiel:
Auftrag wird erstellt, nach 10 Min reißt die Verbindung ab. W-Lan, Verbindung zum Server, SQL-Dienst Neustart durch forciertes Update oder was auch immer.

Wawi: Hängt sich auf, fängt sich nicht mehr ein. Irgendwann wird der Prozess dann ganz beendet. Datenverlust.

Seit Jahren ein Problem, seit Jahren ungelöst. Die Frage ist selbstverständlich rein rhetorisch.

 

[T4DT.GmbH]

Ist es tatsächlich unmöglich, eine Software zu programmieren, die mit Verbindungsabbrüchen gut umgehen kann?
...

Das ist architekturell leider unumgänglich und wird i.d.R. dadurch gelöst, dass mobile Arbeitsplätze ausschließlich per RDP arbeiten (dringlich empfohlen).

Das SQL-Protokoll ist explizit NICHT verbindungsresistent und somit für einen beweglichen Arbeitsplatz ungeeignet.

Fazit: Das hat nichts mit JTL zu tun, sondern damit, dass die Wawi sich per SQL verbindet.
Verbindet sich der Benutzer via RDP, besteht das Problem grundsätzlich nicht.
Ebenso besteht das Problem künftig bei Verbindungen über den Hub / das Cloud ERP (vermutlich 2.2) nicht mehr

 

[intrinsicforce]

Fazit: Das hat nichts mit JTL zu tun, sondern damit, dass die Wawi sich per SQL verbindet.

Nein, JTL hat 1. das SQL-Protokoll für die Software ausgewählt und ist damit auch direkt verantwortlich für die damit einhergehende Problematik; 2. gibt es mehr als nur eine Lösung, um zumindest Datenverluste in solchen Fällen zu vermeiden. Da braucht es jetzt auch nicht allzu viel Kreativität für.

Verbindet sich der Benutzer via RDP, besteht das Problem grundsätzlich nicht.

Falsch, wenn ein forciertes Update den SQL Server neustarten lässt, besteht das Problem auch bei RDP.
Außerdem ist RDP bei Nutzung von ein oder mehreren clientseitig lokalisierten Druckern einem User unter Windows nicht zumutbar.

Ebenso besteht das Problem künftig bei Verbindungen über den Hub / das Cloud ERP (vermutlich 2.2) nicht mehr

Schon klar, deswegen wird hier auch nichts passieren.

 

[NoOne]

Nein, JTL hat 1. das SQL-Protokoll für die Software ausgewählt und ist damit auch direkt verantwortlich für die damit einhergehende Problematik; 2. gibt es mehr als nur eine Lösung, um zumindest Datenverluste in solchen Fällen zu vermeiden. Da braucht es jetzt auch nicht allzu viel Kreativität für.

1. SQL ist kein Protokoll sondern eine Abfragesprache. SQL ist tatsächlich auch nicht das Problem an der Sache. Die Wawi kommuniziert direkt mit dem Datenbankserver. Da gibt es keinen Abstractionlayer zwischen. Der "Datenverlust" bezieht sich ausschließlich auf die Daten die im Client vorhanden sind, aber noch nicht in die DB geschrieben wurden. Du kannst die Daten aber nicht einfach so vorhalten, weil die Datenbank in dem Fall mehrere Clients bedient. Das heißt, du könntest auf keinen Fall irgendwelche IDs und Keys lokal zwischenspeichern und es später nochmal damit versuchen. Weil das absolut schiefgehen würde. Die Wawi-DB ist ziemlich abhängig von den Relationen. Man könnte allerhöchstens explizite User-Eingaben (wie Beschreibungen) zwischenspeichern. Machst du das mit Herstellern oder Kundengruppen wirst du bei Verbindungsproblemen irgendwann auf Inkonsistenzen stoßen. Und das möchtest du nicht, darauf gebe ich dir Brief und Siegel.

2. Das macht die Lösung um Datenverlust zu vermeiden weniger trivial als du vielleicht denkst. Das würde großflächige Umarbeitungen in der kompletten Wawi bedeuten. Nämlich weg vom "Fat-Client" und hin zu (zum Beispiel) einer zwischengeschalteten API oder einem Application-Server der dafür sorgt, dass die Relationen immer korrekt bleiben. Und das mit der bestehenden Software zu machen, ist relativ utopisch. Zumindest in kurzer Zeit.

Alles in allem ist es dir mit Sicherheit lieber, einen gerade erstellten Auftrag nochmal neu machen zu müssen, als dir die komplette DB zu zerschießen.

 

[Peeters]

JTL ist mit diesem Problem nicht alleine, und die von uns genutzte Software vor JTL hatte das gleiche Problem.

 

[intrinsicforce]

Der "Datenverlust" bezieht sich ausschließlich auf die Daten die im Client vorhanden sind, aber noch nicht in die DB geschrieben wurden.

Richtig, also packen wir genau da an. Wenn ein Auftrag geöffnet wird, wird er für andere Benutzer zur Bearbeitung gesperrt. In diesem Zustand könnte man doch Änderungen in einzelnen Feldern in die DB schreiben, sobald der Fokus das Feld verlässt. Bei Verbindungsabbruch kann dann zB gefragt werden, ob die zwischengespeicherte Version wiederhergestellt werden soll, und erst beim Klick auf Speichern wird dann endgültig geschrieben.

 

[NoOne]

Nein, geht nicht. Teilweise geschriebene Aufträge und noch nicht vollständig vorhandene Relationen zu anderen Tabellen wären extrem fehleranfällig. Außerdem gibt es Pflichtfelder (Stichwort „NOT NULL“). Bevor die nicht alle gefüllt sind, *können* die Datensätze gar nicht gespeichert werden. Im besten Fall bleibt Datenmüll zurück, im schlechtesten Fall zerschießt du Zuordnungen/Relationen damit. Wenn du andererseits die Transaktion so lange offen hältst, bis sie "endgültig geschrieben" wird, dann sperrst du ggf. komplette Tabellen für alle anderen Nutzer. Und das *nicht* in der Haupt-DB zu machen, sondern ggf. in einer lokalen Datei/SQLite/anderen Datenbank, geht auch nicht wirklich. Man kann einen noch nicht vorhandenen Datensatz in der Haupt-DB nicht für andere Nutzer sperren und auf die lokale DB hätte kein anderer Client Zugriff.

Und das in einer anderen Tabelle auf dem Server zu speichern, löst dein Problem nicht. Wenn die Verbindung zum Server abbricht, dann kannst du da auch nichts speichern oder lesen -> Du hast wieder 'Datenverlust'. Ggf. weniger, true aber: Mal ganz davon abgesehen, dass du dann auch eine potenziell hohe Belastung des SQL-Servers haben würdest, weil du viele Tables der Datenbank doppeln müsstest und schauen, dass die Relationen der Haupttabellen untereinander stimmen, die Relationen der Nebentabellen untereinander stimmen und beim 'endgültigen Schreiben' die Relationen der Datensätze der Nebentabellen mit denen der Haupttabellen übereinstimmen. Das wäre ein absoluter Albtraum.

Im Allgemeinen ist das natürlich möglich, wenn man das im Voraus so plant. Aber um das jetzt aktuell in der Wawi umzusetzen, müsste man praktisch das komplette DB-Backend umkrempeln. Wie gesagt: Nicht trivial.

 

[intrinsicforce]

Im Allgemeinen ist das natürlich möglich, wenn man das im Voraus so plant. Aber um das jetzt aktuell in der Wawi umzusetzen, müsste man praktisch das komplette DB-Backend umkrempeln. Wie gesagt: Nicht trivial.

Das wird wie gesagt sowieso nicht umgesetzt. Das alles hier ist nur ein rage post ohne irgendwas an den Plänen von JTL zu bewirken. Bin angefressen von dem Zeitverlust der kumuliert nicht ohne ist. Zu sehen dass es sich ohnehin nicht einfach ändern lässt beruhigt mich paradoxerweise. Ziel erreicht.

Langfristig geht es eh in die Cloud, und da wird sich dann ein gigantischer Leckerbissen für diverse Interessenten bilden die das ganze Ding dann infiltrieren und die Daten entweder weiterverticken oder selbst benutzen. Gefällt mir aber irgendwie besser als wenn mein Server auseinandergenommen wird und ich dann alleine in Haftung genommen werde für den Schaden.

Also denn, weiter geht's! Letztendlich wird doch alles gut.
😛