Verbindung eines ERP-Systems zu einer SQL Datenbank.

[willy-goergen 0]

Heute kam bei einem Telefonat mit der Entwicklerin von unserem ERP-System wieder das Thema zwecks Verbindungsproblemen in unserem Firmennetzwerk auf. Der Grund dafür waren Logdateien ihres Programmes, die ich ihr zur Fehlerbereinigung geschickt hatte.

 

Mit der guten Frau hatte ich wegen der angeblichen Netzwerkfehler schon die eine oder andere Diskussion. Ich will das nicht zu sehr in die Länge ziehen.

 

Unser ERP-System (eine Lösung von einem kleinen Softwarehaus) ist Modular aufgebaut und setzt auf eine MS SQL Datenbank. Das heißt, es gibt im Programm verschiedene Module. Beispielsweise Fertigung, QS, Zeiterfassung, etc.

 

Beim Öffnen des jeweiligen Moduls wird eine Verbindung zur SQL-Datenbank aufgebaut, die erst beim Beenden des Moduls wieder geschlossen wird. Das heißt, das offene Transaktionen vielleicht erst beim Beenden durchgeführt werden.

 

Tritt in dieser Zeit, die gerne mal mehrere Stunden oder Tage sein kann, ein "Wackler" im Netzwerk auf, wird auch nichts mehr zurückgeschrieben und es gibt Datenverlust.

 

Meiner Meinung nach sollte ihr Programm so gestaltet sein, dass es für solche "Wackler" unempfindlich ist.

Momentan probiert sie mir den schwarzen Peter dafür zuzuschieben. Ich bin der Meinung, dass die Verbindung zur Datenbank nur im Fall einer Transaktion aufgebaut werden darf. Nach dem Abschluss der Transaktion muss die Verbindung wieder beendet werden.

 

Sorry, für wenn ich es sehr allgemein gehalten habe. Ich kann bei Bedarf auch nähere Infos liefern. Mich interessiert erst mal, wie ihr das mit der stets offenen Verbindung vom ERP-System zur SQL-Datenbank seht. In meinen Augen wird das Programm dadurch sehr fehleranfällig.

bearbeitet 1. April 2015 von willy-goergen

[NilsK 2.934]

Moin,

 

ob es tatsächlich so ist, wie du es beschreibst, lässt sich ohne exakte Analyse des Codes und der tatsächlichen Vorgänge nicht beurteilen. Allgemein sollten natürlich Transaktionen so kurz wie möglich gehalten werden. Neben Abbrüchen könnte es sonst auch zu Sperrkonflikten usw. kommen.

 

Es wäre allerdings sehr ungewöhnlich, wenn das Programm sich tatsächlich so verhalten würde, wie du beschreibst. Daher gebe ich hier keine Bewertung ab. Nur so viel: In komplexen Situationen wie der beschriebenen liegen die Dinge oftmals anders, als man denkt.

 

Dass du selbst allerdings einräumst, dass es "Wackler" im Netzwerk gibt, sollte dich zu einer gewissen Kooperationsbereitschaft bringen.

 

Gruß, Nils

[Doso 77]

Was du beschreibst, wenn es denn zutrifft, wäre in der Tat eine äußerst unsaubere Methode erp software zu programmieren. Trotzdem solltest du die Wackler im Netzwerk beseitigen. Sei es nur darum das du dem Anbieter dann sagen kannst, das es die Ausfälle nicht gibt und ihre Software immer noch mies ist.

[willy-goergen 0]

Es wäre allerdings sehr ungewöhnlich, wenn das Programm sich tatsächlich so verhalten würde, wie du beschreibst. Daher gebe ich hier keine Bewertung ab. Nur so viel: In komplexen Situationen wie der beschriebenen liegen die Dinge oftmals anders, als man denkt.

 

Dass du selbst allerdings einräumst, dass es "Wackler" im Netzwerk gibt, sollte dich zu einer gewissen Kooperationsbereitschaft bringen.

 

Gruß, Nils

 

Eventuell geht meine Frage eher in den konzeptionellen Bereich.

 

Die Entwicklerin hat mir das in einem Gespräch gestern so offenbart. Selbst habe ich leider auch keinen Einblick in den Quellcode. Sie hält es selbst für die beste Lösung, die Verbindung stets aufrecht zu erhalten, um nicht so sehr viel Traffic im Netzwerk zu erzeugen. Sicher, ich kann mich auch täuschen. Ich teile im Moment die Meinung, dass die Verbindung möglichst kurz zu halten ist.

 

Ich bin mir sehr sicher, dass dem Firmennetz nicht viel fehlt. Neben der kleinen Datenbank für das ERP-System haben wir auch noch ein richtiges PDM und Lagerverwaltungssystem (für ein Lager) mit MS SQL-Datenbank im Einsatz, das absolut problemlos läuft. Ein zweites Lager mit MS SQL-Datenbank kommt demnächst dazu.

 

Meinen eingeräumten "Wackler" solltest du dahingehend interpretieren, dass er passieren kann. Ich hatte mich selbst erst die Tage mit diesem möglichen Fehlerfall auseinander gesetzt. Normal wäre das nicht...

 

Im Fall von dem ERP-System müsste ich laut der Entwicklerin durch die Firma laufen und überprüfen, ob an jedem Client das Programm geschlossen ist, bevor ich den Server mit der Datenbank für das ERP-System neu starte. Ich halte das für wenig praktikabel, auch wenn ich etwas Übergewicht habe. Wenn ich fertig bin, hat da wo ich angefangen habe, schon wieder der erste das Programm am Laufen. Den Prozess in der Domäne einfach zu töten wäre auch keine Lösung, da wieder Datenverlust.

 

Ich denke, diesen ungewöhnlichen Fall habe ich hier. Ich bin eigentlich kurz davor der Entwicklerin die Vorgabe zu machen, dass sie ihr Programm umstricken muss.

 

Grüße, Jörg

 

EDIT:

Die Sperrkonflikte gibt es.

 

Ich geb jetzt ein Beispiel und hoffe, dass mich keiner verpetzt.

Fehlermeldung bei der Methode Satzändern: Speichern Daten nach Drucken bei Angebot-Nr.: *: 
Das aktuelle Recordset unterstützt keine Aktualisierung.  Hierbei handelt es sich möglicherweise um eine Einschränkung seitens des Providers oder des gewählten LockTypes.( 3251)
02.03.2015 13:16:30 

bearbeitet 1. April 2015 von willy-goergen

[zahni 554]

Das kann viele Ursachen haben, wie schon geschrieben, Nicht unterstütze SQL-Version, irgendwelche Parameter im SQL-Server eingestellt, etc...

Das Client-Programme immer eine Connection offen halten, ist durchaus normal. Allerdings sollten da keine Transaktionen ewig offen bleiben.

Denkbar wäre aber, dass ein Client-Programm einen Record-Lock setzt, wenn ein User einen Datensatz öffnet.

Aber selbst dabei entstehen keine Datenverluste. Hier sind maximal die Eingaben des Users weg.

bearbeitet 1. April 2015 von zahni

[willy-goergen 0]

Das kann viele Ursachen haben, wie schon geschrieben, Nicht unterstütze SQL-Version, irgendwelche Parameter im SQL-Server eingestellt, etc...

 

Dieser SQL-Server wurde von der Firma eingerichtet, die uns die Software verkaufen will, damals in meinen Anfangstagen. Für mich ist das alles in allem eine absolute Krücke. Aber davon hängt das Tagesgeschäft ab...

 

Ich reiße mich eigentlich jeden Tag nur zusammen.

Aber selbst dabei entstehen keine Datenverluste. Hier sind maximal die Eingaben des Users weg.

 

Wenn die Eingaben des Users weg sind, ist das für mich ein Datenverlust. Oder täusche ich mich da?

bearbeitet 1. April 2015 von willy-goergen

[zahni 554]

Dann gibt der User die Daten halt neu ein. Er bekommt doch eine FM?

Ansonsten schließe ich mich der Meinung von Nils an: Such die Fehler im Netzwerk, die Du vermutlich hast.

[Dukel 454]

Wenn die Eingaben des Users weg sind, ist das für mich ein Datenverlust. Oder täusche ich mich da?

 

Das ist so gewollt.

Willst du lieber, dass ein undefinierter Zustand in der DB eingetragen ist?

[NeMiX 76]

Das ist so gewollt.

Willst du lieber, dass ein undefinierter Zustand in der DB eingetragen ist?

 

Ich glaube der TO möchte/erwartet das wenn ein User Daten eingibt diese sauber weggeschrieben werden und nicht erst wenn er das Programm schließt.

 

@TO: Wie definierst du den Wackler im Netzwerk? Schon mal auf den Switchen geschaut ob da Pakete gedroppt werden? PRTG bietet 100 Sensoren for free an, evtl. das mal in einer VM installieren und die Switche monitoren. Dann hast du auch mal was schriftlich und kannst die Diskussion mit den Entwickler mit Daten untermauern.

[willy-goergen 0]

Ich glaube der TO möchte/erwartet das wenn ein User Daten eingibt diese sauber weggeschrieben werden und nicht erst wenn er das Programm schließt.

 

@TO: Wie definierst du den Wackler im Netzwerk? Schon mal auf den Switchen geschaut ob da Pakete gedroppt werden? PRTG bietet 100 Sensoren for free an, evtl. das mal in einer VM installieren und die Switche monitoren. Dann hast du auch mal was schriftlich und kannst die Diskussion mit den Entwickler mit Daten untermauern.

 

Richtig. So in etwa würde ich mir das vorstellen. 

 

Aktuell bleibt das Programm hängen, wenn ich den Server mit der Datenbank wegen monatlichen Updates neu starte. Das wäre der übliche Fall. Eine Rückmeldung, dass die Verbindung zur Datenbank am Client verloren wurde, gibt es dabei nicht. Die Verbindung wird vom Client auch nicht mehr neu aufgebaut, wenn der Server nach dem Neustart wieder da ist.

 

Man kann ggf. erst mal mit dem Programm weiter arbeiten und seine Eingabe weiter vervollständigen. Wenn dann auf die Datenbank zugegriffen werden soll, kommt immer wieder diese Fehlermeldung am Client:

Fehlermeldung bei der Methode Suche Datensatz -SELECT * FROM Bierkasten WHERE Flasche=1: 
(0) Microsoft OLE DB Provider for SQL Server: Fehler beim Verbinden (SQLState: 08S01) (Fehlercode (hexadezimal): 80004005)

Die SQL-Anweisung sieht dabei von Fall zu Fall anders aus. In dem Beispiel hab ich etwas nachgeholfen. (ich denke, man sieht es)

Wie gesagt... der Server ist dann u.U. schon wieder Online. Man kann dann beliebig auf den "Speichern" oder "Beenden" Button hämmern und bekommt immer wieder obige Fehlermeldung. Um da raus zu kommen, müssen die User das Programm über den Task-Manager abwürgen. Das Programm merkt erst nach einem Neustart, dass der Server schon lange wieder da ist. 

 

Etwas problematisch ist die Sache, weil die Firma, die das Programm entwickelt, das Problem von sich wegschieben will. Es wird nur auf Grundlage der obigen Meldung behauptet, dass das Firmennetz fehlerhaft sei, weswegen es dann unser Problem ist, wenn die Datenbank fehlerhaft wird. Auch andere Fehlermeldungen, wie die aus meinem Post #4, werden durch diesen SQL-Fehler erklärt. Die Datenbank sei durch den 08S01-Fehler bereits beschädigt, weswegen nun ein weiterer Fehler auftritt.

 

Das Thema hat einen ziemlichen Rattenschwanz und mir geht die ständige Diskussion darüber mittlerweile ziemlich auf die Nerven.

Darüber, wie ich belastbares Material als Diskussionsgrundlage sammeln kann, habe ich mir auch schon Gedanken gemacht.

 

Mein Gedanke war mit einem professionellen Netzwerktester sämtliche Ports zu testen und dabei gleich alles zu dokumentieren. Das möchte die Entwicklerin aber nicht gelten lassen, weil die Möglichkeit besteht, dass nach dem Testen wieder irgendwas am Netzwerk kaputt geht.

 

Das ganze zu Monitoren habe ich mir danach auch schon überlegt. Wie ich das machen könnte, wusste ich bisher noch nicht so recht. Danke für den Tipp mit PRTG! :)

 

Danke euch allen erst mal bis hier her für die guten Tipps. Ich denke, ich arbeite mal die beiden Punkte (verworfene Pakete und Monitoring) ab und sehe, was dabei herauskommt.

bearbeitet 2. April 2015 von willy-goergen

[Dukel 454]

Ich glaube der TO möchte/erwartet das wenn ein User Daten eingibt diese sauber weggeschrieben werden und nicht erst wenn er das Programm schließt.

 

Ist das so? Sind _alle_ Eingaben einer Session weg, wenn die Verbindung abbricht oder nur die zuletzt Eingegebenen Eingaben (und ggf. nicht gespeicherten)?

 

Ist das eine Eigenentwicklung für euch oder wird die Software generell verkauft? Wurden Anforderungen definiert, wie sich die Software in dem Fall verhalten soll?

[Sunny61 806]

Richtig. So in etwa würde ich mir das vorstellen.

Dann muss bei jeder Aktion vorher gegen die SQL Datenbank geprüft werden, ob die Verbindung steht oder nicht. Wenn nicht, aufbauen, fertig. So ähnlich mach ich das auch.

 

Aktuell bleibt das Programm hängen, wenn ich den Server mit der Datenbank wegen monatlichen Updates neu starte. Das wäre der übliche Fall. Eine Rückmeldung, dass die Verbindung zur Datenbank am Client verloren wurde, gibt es dabei nicht. Die Verbindung wird vom Client auch nicht mehr neu aufgebaut, wenn der Server nach dem Neustart wieder da ist.

Den SQL Server solltest Du an der Stelle aber auch nicht im laufenden Betrieb neu starten, sondern in der Nacht per geplantem Task.

 

die von dir reklamierten Dinge schriftlich niederlegen, der GF vorlegen und dann an den Hersteller weiter reichen, hier darüber zu diskutieren ist der falsche Ort.

 

Danke euch allen erst mal bis hier her für die guten Tipps. Ich denke, ich arbeite mal die beiden Punkte (verworfene Pakete und Monitoring) ab und sehe, was dabei herauskommt.

Prüf auch die eingesetzte Firmware auf den Switchen, manchmal hilft das aktualisieren. ;)

[NorbertFe 2.034]

Prüf auch die eingesetzte Firmware auf den Switchen, manchmal hilft das aktualisieren. ;)

Wenn der Wackler aus einem Reboot des Servers zwecks Updates besteht, dann hilft auch die Firmware auf den Switchen nicht. ;)

[Sunny61 806]

Wenn der Wackler aus einem Reboot des Servers zwecks Updates besteht, dann hilft auch die Firmware auf den Switchen nicht. ;)

Das ist richtig, wir hatten hier vor ein paar Jahren immer wieder solche Wackler, die Aktualisierung der Firmware brachte eindeutige Verbesserung. ;)

[willy-goergen 0]

Dann muss bei jeder Aktion vorher gegen die SQL Datenbank geprüft werden, ob die Verbindung steht oder nicht. Wenn nicht, aufbauen, fertig. So ähnlich mach ich das auch.

 

So oder so ähnlich könnte/sollte das meiner Meinung nach auch aussehen. Momentan gibt es gar keine Prüfung.

 

 

Den SQL Server solltest Du an der Stelle aber auch nicht im laufenden Betrieb neu starten, sondern in der Nacht per geplantem Task.

 

Ich starte den Server für Updates normalerweise nicht im laufenden Betrieb. Ich mache das abends, wenn hier (fast) keiner mehr ist. Das Problem dabei sind die Clients in der Produktion, die teilweise durchlaufen. Die werden von Mitarbeitern für die Rückmeldung der erledigten Aufträge benutzt. An denen ist das ERP-Programm permanent geöffnet und der SQL-Fehler tritt oft erst viele Stunden nach einem Serverneustart auf, weil es bis zum Zeitpunkt der Rückmeldung keine Eingabe im ERP-System gegeben hat.

 

Wenn ich den Server jetzt per geplantem Task nachts neu starten würde, bekommt der erste Mitarbeiter, der morgens etwas Rückmelden will, den Fehler präsentiert.

 

 

die von dir reklamierten Dinge schriftlich niederlegen, der GF vorlegen und dann an den Hersteller weiter reichen, hier darüber zu diskutieren ist der falsche Ort.

 

 

Richtig und richtig. Ich muss die Sache mit der Geschäftsführung diskutieren. Vor allem Anwendung eines Programms zum Monitoring des Netzwerks muss ich mit der GF abklären. Hier sicher der falsche Ort die Diskussion weiter zu führen. Ich bin allerdings mal wieder sehr froh über den positiven Input zu der Sache gewesen. :)