Schreiben in die Datenbank macht Endlosschleife

[ULIK]

Versteh ich das richtig: das Write auf der DB wird ausgelöst, kommt aber nicht zurück? Könnten hier DB Trigger rein spielen, die einen Lock erzeugen? Ich kenn mich jetzt mit MSSQL nicht aus, aber hast Du schon mal auf der DB nachgeschaut, ob Du dort etwas über das ausgeführte Statement heraus findest (Oracle hatte da was, wenn ich mich recht erinnere).

[haentschman]

Zitat:

Versteh ich das richtig: das Write auf der DB wird ausgelöst, kommt aber nicht zurück?

...ja, aber nur an einem Datensatz an einem bestimmten Arbeitsplatz reproduzierbar.

Zitat:

Könnten hier DB Trigger rein spielen

...diese Tabelle hat keine Trigger.

Zitat:

über das ausgeführte Statement heraus findest

...gut Idee. Das Statement ist aber an allen Plätzen das gleiche...

PS:
Der Timeout stand auf 600 Sekunden. Zum Test auf 60 Sekunden reduziert.

[ULIK]

Das mit dem DB Trigger war eine Idee, weil der Code was von DB Trigger bzgl. Historie schrieb: DMZU.Database.Write(FModifiedDistributor, CanSaveHistorie); // Historie siehe DB Trigger

Zitat:

Zitat:
über das ausgeführte Statement heraus findest
...gut Idee. Das Statement ist aber an allen Plätzen das gleiche...

Aber wenn hier ein eventueller Langläufer auftritt, könntest Du so eventuell herausfinden, was genau die Ausführung verzögert. Und MSSQL hat so was anscheinend: https://learn.microsoft.com/en-us/tr...unning-queries

[haentschman]

Zitat:

// Historie siehe DB Trigger

...sorry, das steht noch da. Der Trigger ist aber raus.

[TigerLilly]

Ich würde als erstes mit dem MSSQL Profiler schauen, was der SQL Sver macht, wenn der Datensatz geschrieben wird.
Hängt das Programm (= Endlosschleife in deinem Code) oder hängt der SQL Server (=Locking).

Wenn du das weißt, kann man gezielter weitermachen.

Keinesfalls würde ich (jetzt schon) herumprobieren (neu starten, Hardware tauschen etc). Im besten Fall hilft es nichts, im schlechtesten Fall ist das Problem dann weg + du weißt nicht wieso.

[haentschman]

Neuigkeiten:

1. Das alte Kabel vom Computer zur Dose hatte einen Knick was zu höheren Kurvengeschwindigkeiten für die Daten führt. (Wer den witzigen Forumseintrag über Kabelverlegung findet, kann ihn gern mal anhängen. Ich habe ihn nicht gefunden. )
2. Kabel getauscht (gleiche Dose) -> gleicher Fehler am gleichen Datensatz
3. neues Kabel an neuer Dose -> Speicherung korrekt.
4. altes Kabel an neuer Dose -> Speicherung korrekt.

...nächste Woche muß der externe IT Fuzzi mal die Dose/Port durchmessen.

Trotzdem ist es unlogisch...

[stifflersmom]

Da mit neuem und altem Kabel die Speicherung an anderer Dose korrekt ist kommen nur noch vier Möglichkeiten in Frage:

- Dose selbst
- entsprechender Port auf Patchfeld
- Patchkabel vom Patchfeld zum Switch
- Port auf Switch selbst

Ich persönlich tippe auf dem Switch.

[TomyN]

Ich persönlich auch (Firewall Regel, Filter oder oder ..)