Schreiben in die Datenbank macht Endlosschleife

[haentschman]

Hallöle...8-)

gegeben:
* mehrere Arbeitsplätze
* exakt gleiche EXE an jedem Arbeitsplatz
* gleicher Native MSSQL Treiber an jedem Arbeitsplatz
* gleiche Daten aus der selben Tabelle der gleichen Datenbank

Ich habe an einem Arbeitsplatz folgendes Problem:
* jegliche Änderung am gleichen Datensatz -> Speichern bringt eine Endlosschleife (nach 10 Minuten abgebrochen) :kotz:
* reproduzierbar am gleichen Datensatz (an anderen Arbeitsplätzen kann dieser Datensatz gespeichert werden :shock:)
* auch nach dem Speichern an einem anderen Platz kann der geänderte Datensatz nicht gespeichert werden. :shock:
* keine Fehler im Programm, keine Fehler im EventLog


Technologie:
nackige Query mit ExecSQL.


...ich habe keine Idee. :?

Morgen werde ich mal den TimeOut der Datenbank prüfen...ggf. auf kurz setzen. Dann prüfe ich die Größe der Felder...eigentlich kommt dann direkt ein Fehler.

Danke für Infos. :wink:

[TomyN]

Gleiche OS Version auf allen Rechnern? Evtl. 32/64 Problematik?

Tritt das Problem bei einem speziellen Datensatz oder bei allen Datensätzen auf?

[haentschman]

Moin...8-)

Zitat:

Gleiche OS Version auf allen Rechnern? Evtl. 32/64 Problematik?

W11, 64Bit überall gleich

Zitat:

Tritt das Problem bei einem speziellen Datensatz oder bei allen Datensätzen auf?

...nur ein Datensatz. Alle anderen lassen sich problemlos speichern. In der Zwischenzeit (3 Monate) hatte dieser Arbeitsplatz 3 verschiedene Datensätze die betroffen waren.
PS: In diesem "Modul" werden an diesem Platz ca. 100 Änderungen an verschieden Datensätzen gemacht. Nur dieser eine will nicht.

Zitat:

// korrekt
Distributor: 18.09.2024 14:24:15 - START FOnChangeGridBegin
Distributor: 18.09.2024 14:24:15 - END FOnChangeGridBegin
Distributor: 18.09.2024 14:24:15 - START Database.Write - 9025
Distributor: 18.09.2024 14:24:15 - END Database.Write - 9025
Distributor: 18.09.2024 14:24:15 - START Assign
Distributor: 18.09.2024 14:24:15 - END Assign
Distributor: 18.09.2024 14:24:15 - START FOnChangeGridEnd
Distributor: 18.09.2024 14:24:15 - END FOnChangeGridEnd
------
// Fehler
Distributor: 18.09.2024 14:24:50 - START FOnChangeGridBegin
Distributor: 18.09.2024 14:24:50 - END FOnChangeGridBegin
Distributor: 18.09.2024 14:24:50 - START Database.Write - 7242

Delphi-Quellcode:

procedure TFormDistributorLogic.SaveDistributor;

  function CanSaveHistorie: Boolean;
  begin
    Result := not ((FModifiedDistributor.StateInternType = FOriginalDistributor.StateInternType) and
                   (FModifiedDistributor.ResponsibleTo = FOriginalDistributor.ResponsibleTo) and
                   (FModifiedDistributor.DocumentChoice = FOriginalDistributor.DocumentChoice));
  end;

begin
  if Assigned(FOnChangeGridBegin) then
  begin
    FOnChangeGridBegin(Self);
  end;

  DMZU.Database.Write(FModifiedDistributor, CanSaveHistorie); // Historie siehe DB Trigger
  FDistributorDatasource.Changed := True;
  FModifiedDistributor.IsChanged := False; // setzt auf normal

  FOriginalDistributor.Assign(FModifiedDistributor);

  if Assigned(FOnChangeGridEnd) then
  begin
    FOnChangeGridEnd(Self);
  end;
end;

[stifflersmom]

Kann es vielleicht die Technik darunter sein?
Also vielleicht ein Fehler im Netzwerk?
Auch wenn ich mir nicht vorstellen kann, dass das nur einen spezifischen Datensatz betreffen sollte.

Hast Du den SQL-Server schon mal neu gestartet?

[fisipjm]

Moin,

Was macht dein FOnchangeGridStart und FOnChangeGridEnd?
hast du irgendwas in Richtung Livebinding auf dem Grid liegen?
Das wird nämlich durch eine Datasource änderung ein GridChange triggern.

Gruß
PJM

[haentschman]

Danke...8-)

Zitat:

Was macht dein FOnchangeGridStart und FOnChangeGridEnd?

Delphi-Quellcode:

procedure TfoDistributor.DoOnChangeGridBegin(Sender: TObject);
begin
  if Assigned(FLogic.ModifiedDistributor) then
  begin
    FLogic.DistributorDatasource.LastID := FLogic.ModifiedDistributor.ID;
  end;
  gtvDistributor.BeginUpdate;
end;

procedure TfoDistributor.DoOnChangeGridEnd(Sender: TObject);
begin
  // wichtig!
  gtvDistributor.EndUpdate;
  TToolsDevExpress.SelectRecord(gtvDistributor, 0, FLogic.DistributorDatasource.LastID, null); 
end;

Zitat:

hast du irgendwas in Richtung Livebinding auf dem Grid liegen?

nein...Gott sei Dank.:zwinker:

Zitat:

Also vielleicht ein Fehler im Netzwerk?

..die Idee hatte ich auch schon. Früher mal hatten wir auch an einem anderem Platz Probleme mit Daten nicht gefunden (oder so ähnlich)...obwohl das Programm fehlerfrei lief. Vom Schwitch ein neues Kabel gezogen...Fehler weg. Dieser Arbeitsplatz ist aber neu mit neuen Kabeln...was nichts heißen mag. :wink:

Zitat:

Hast Du den SQL-Server schon mal neu gestartet?

Ja. Ohne Erfolg.

Zitat:

Auch wenn ich mir nicht vorstellen kann, dass das nur einen spezifischen Datensatz betreffen sollte.

Das ist auch das was meine Logic nicht versteht. :? Das ist aber so und reproduzierbar...

[TomyN]

Hat der Datensatz was besonderes, evtl. Umlaute (Evtl. unterschiedliche Zeichensätze/Sprachen auf den Rechnern?)

[haentschman]

Zitat:

Hat der Datensatz was besonderes, evtl. Umlaute

ja, bei den anderen Arbeitslätzen aber auch...dort läßt sich das speichern. Unlogisch, ich weiß. :roll:

Zitat:

Evtl. unterschiedliche Zeichensätze/Sprachen auf den Rechnern?

nein...alles nur deutsch.

[stifflersmom]

Wenn Du kannst, versuch doch, auch wenn der Rechner neu ist, einen andere Netzwerkkarte und / oder Kabel... oder tatsächlich einen anderen Port auf dem Netzwerkswitch.

[haentschman]

Zitat:

einen andere Netzwerkkarte und / oder Kabe

Kabel und in andere Dose mache ich wenn die Mitarbeiterin heute da ist...Spätschicht. Netzwerkkarte und anderen Port auf dem Netzwerkswitch macht unser externer IT Fuzzi...:wink:

[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. :zwinker:

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:

Delphi-Quellcode:

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. :stupid: :zwinker: (Wer den witzigen Forumseintrag über Kabelverlegung findet, kann ihn gern mal anhängen. Ich habe ihn nicht gefunden. :wink:)
2. Kabel getauscht (gleiche Dose) -> gleicher Fehler am gleichen Datensatz :?
3. neues Kabel an neuer Dose -> Speicherung korrekt. :cheer:
4. altes Kabel an neuer Dose -> Speicherung korrekt. :cheer:

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

Trotzdem ist es unlogisch...:gruebel:

[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 ..)