FireDAC: Endlosschleife bei Post auf FDTable

[ioster]

Moin,

ich habe eine elementares Problem bei einem Kunden, der meine Software (Delphi 10.3, FireDAC und DevExpress-Komponenten) in Kombination mit einem MS SQL Server 2014 einsetzt.

Es betrifft die immens wichtige Adresstabelle, die kein Post mehr verkraftet. Ich kann es per Fernwartung mit dem Debugger eingrenzen und komme immer bis zu der Stelle, wo das Dataset ein Post bekommt. Über den SQL-Profiler kann ich auch erkennen, dass ein UPDATE-Befehl an die Datenbank gesendet wird. Die Felder und Parameter sind auch in Ordnung, aber die Datenbank kann den Befehl nicht abarbeiten.

Vor Ostern konnten die Adressen noch problemlos angelegt und bearbeitet werden, aber seit vorgestern ist der Wurm drin. Ich habe jetzt schon die Datenbank offline und online geschaltet, die Indizes neu aufgebaut und auch das Autoinc-Feld, das im PRIMARY Key verwendet wird, neu generiert. Es hilft alles nichts.

Um auszuschließen, dass das Problem aus einem kürzlich eingespielten Programmupdate resultiert, habe ich auch die Vorgängerversion ausprobiert. Das macht keinen Unterschied und bestärkt mich darin, dass die Datenbank das Kernproblem darstellt. Ich habe nun auch schon eine Testdatenbank generiert und konnte das Problem beheben, in dem ich die Adresstabelle leere. Fülle ich sie mit den 12.000 Datensätzen wieder, habe ich erneut das Problem.

Woran kann so etwas liegen, wenn ich über das Management-Studio die Tabelle editieren kann und die anderen Tabellen auch keine Probleme bereiten. Es sind gut und gerne 50 Tabellen, die von dem Programm verwaltet werden. Der Adressstamm besteht auch aus mehreren Tabellen, die auch im Dialog eingebunden sind. Anhand der Ablaufverfolgung ist es aber eindeutig die Adresstabelle. Es macht auch keinen Unterschied, ob das Post vom cxDBNavigator oder mit einem bewussten Aufruf der Post-Methode ausgelöst wird.

Ich wäre für technische Tipps dankbar.

Viele Grüße
Ingo

[Uwe Raabe]

Falls es sich um die SQL Server Express Edition handelt, könnte die dort geltende Größenbeschränkung für die Datenbank zuschlagen.

[ioster]

Zitat:

Zitat von Uwe Raabe (Beitrag 1486672)

Falls es sich um die SQL Server Express Edition handelt, könnte die dort geltende Größenbeschränkung für die Datenbank zuschlagen.

Ich habe gerade nachgesehen - es ist in der Tat die Express Edition (64 bit). Die Installation der Datenbanksoftware habe ich selber nicht vorgenommen. Nur die für die Anwendung notwendige Datenbank habe ich angelegt.

Gibt es Größenbeschränkungen auf einzelne Tabellen? Laut Eigenschaften ist die DB im Augenblick 6.975 MB groß und hätte noch Platz für 1.966 MB. Die betroffene Tabelle hat 12.200 Datensätze und verbraucht dabei 25,266 MB.

Ich probiere im Augenblick aus, ob es einen Unterschied macht, wenn ich die ganzen referenzierenden Tabellen im Dialog weglasse. Dann könnte man übergangsweise Name, Straße und Ort erfassen.

Gruß
Ingo

[Sinspin]

Hast du mal manuell via Script probiert einen neuen Datensatz einzufügen? Nicht das irgendwo ein Feld mit Unique Index einen Wert hast den du bisher übersehen hast.
Die DB ist eigentlich zu klein als dass du an Beschränkungen stoßen solltest. Ich habe Tabellen mit mehr als 300K Datensätzen.

[ioster]

Ich habe die Tabelle nun noch einmal in meine Testumgebung kopiert und das Feld INFO für den Infotext entfernt. Das ist vom Typ nvarchar(max). Jetzt kann ich auf der Datenbank die Adressen bearbeiten und speichern.

Auf der echten Datenbank kann ich hingegen nicht einmal mehr über das Management Studio Änderungen an der Tabelle vornehmen. Wenn ich testweise ein Feld ändere, geht das System auch in eine Endlosschleife mit dem Unterschied, dass hier ein Timeout ausgelöst wird. Mit Escape kann ich die Änderung zurücknehmen und die Tabelle wieder verlassen.

Gruß
Ingo

[Uwe Raabe]

Schau mal nach, ob die DB eine Änderungsprotokollierung macht. Ich hatte schon mal den Fall, dass die Logs zu groß wurden.

[ioster]

Es wurde gerade festgestellt, dass eine neue Adresse ohne Probleme erfasst werden konnte. Ich konnte es mit einem INSERT auch bewerkstelligen. Die Adresse, die das ganze Problem ausgelöst hat, ist aber mit einem DELETE nicht wegzuputzen.

Kann man irgendwo einsehen, ob bestimmte Datensätze in den Tabellen gelockt sind? Und wie bekommt man den Status weg? Mit Offline schalten alleine scheint es nicht getan zu sein. Das Problem breitet sich gerade auf die Tabelle aus, in der Angebote gespeichert werden.

[ioster]

Zitat:

Zitat von Uwe Raabe (Beitrag 1486695)

Schau mal nach, ob die DB eine Änderungsprotokollierung macht. Ich hatte schon mal den Fall, dass die Logs zu groß wurden.

Die Änderungsnachverfolgung ist laut Eigenschaften inaktiv. Es wird aber eine Statistik automatisch erstellt, die inzwischen etliche Einträge bei dieser Tabelle umfasst. Die wollte ich vorgestern schon löschen, ist mir aber mit den Mitteln des Management Studios auch nicht gelungen.

[TigerLilly]

Möglicherweise läuft hier etwas in einen Deadlock (Stichwort Lock Escalation) - da kommt aber nach einer Zeit eine Fehlermeldung.
Möglicherweise sind die Indices untauglich, sodass für eien Operation ein Full Table Scan notwnedig wird - das dauert uU, aber führt schlussendlich auch zu einem Ergebnis.

Meldung bekommst du keine?
Wie lange wartest auf ein Ergebnis/Meldung?

Lass den Profiler mitlaufen + schau welches Statement (hier das Update) das problem macht + analysiere das - schau dir den Execution Plan an.

[Delphi.Narium]

Defekte Daten im nvarchar(max)?

Kannst Du beim Update aus Deinem Programm heraus mal diese Spalte weglassen? Geht es dann?

Ansonsten:

Backup und Restore der Datenbank machen?

Wie hast Du die Tabelle in Deine Testumgebung kopiert? Einfach 'ne Kopie der Datenbankdatei genommen oder Backup der Kunden DB und Restore in Deine DB oder ...?

Habe ganz selten mal ähnliche Probleme mit 'ner FireBird-Datenbank. Dann hilft immer ein Backup und ein Restore in eine neue Datenbankdatei.