Datensatz kann nicht gespeichert werden - Prüfsummenfehler bei einem Datensatz

Product :4D - 4D Server
4D : v13.6>OS : Windows
OS : Mac OS X

Hallo,

ich habe bei einer Anwendung das Problem, dass bei genau einem Datensatz ein, für mich, unerklärlicher Fehler wie folgt auftritt:
Es handelt sich um eine Warenwirtschafts-Anwendung (Artikel, Kunden, Aufträge, Auftragspositionen etc.)
Angelegt sind ca. 1.300 Artikel, alle in gleicher oder sehr ähnlicher Weise.

Es werden laufend Aufträge wie folgt erfasst:

  • Suche des Kunden in der Adresstabelle
  • Initieren eines neuen Auftrags mittels Button
  • hinzufügen von Artikeln zu diesem Auftrag (werden dann unter Auftragspositionen gespeichert)

Das Problem tritt beim Hinzufügen des Artikels auf:
Bei 1.299 der 1.300 Artikel läuft alles problemlos wie vorgesehen, aber wenn dieser eine Artikel hinzugefügt wird, wirft 4D folgenden Fehler:

Neuer Datensatz für Tabelle AUFTRAG_POS der Datenbank … kann nicht gespeichert werden
Eintrag in Index AUFTRAG_POS.nummer in Datenbank … kann nicht hinzugefügt werden
Seite für Index AUFTRAG_POS.nummer in Datenbank … kann nicht geladen werden
Falsche Prüfsumme

Der Artikel ist gleicht sich datentechnisch bis auf die Bezeichnung exakt mit anderen Artikeln, er konnte bis vor etwa 6 Wochen auch noch ganz normal verwendet werden.

Folgendes habe ich bereits gemacht:

  • Struktur und Daten mittels MSC geprüft, repariert und komprimiert
  • den betreffenden Datensatz im 4D-Format exportiert, dann den Datensatz umbenannt (neue ID und Nummer), danach den zuvor exportieren wieder importiert.

Leider alles ohne Erfolg, jetzt habe ich keine Idee mehr, wo ich den Fehler finden könnte.

Ich hoffe, jemand hat einen Tip …

Hermann

Hallo Herr Kuffner,

mal das Backup prüfen - ist auf der Platte noch genug Platz für den Logfile (Journal)?

Hallo Herr Schumacher,

danke für die schnelle Antwort!
Ja, auf der Platte ist noch ein halbes TB frei.
Es können ja auch weiterhin Aufträge geschrieben werden, mit allen beliebigen Artikeln, nur eben nicht mit diesem einen …

Inzwischen habe ich noch was interessantes herausgefunden, vielleicht hilft das:

die Artikel sind so konzipiert, dass sie eine aut. generierte eindeutige ID (longint, per Trigger vergeben) erhalten, außerdem haben sie aber noch eine sogenannte Artikelnummer (alpha für den Firmenkatalog), die ebenfalls eindeutig und indiziert ist, aber manuell eingepflegt wird.
Die Relation läuft natürlich auf Basis der aut. ID.

Wenn ich nun bei diesem beschriebenen Artikel die Firmennummer (Artikelnummer) ändere, wird er akzeptiert, das Ändern der aut. ID hingegen hilft nicht. Das ist recht suspekt und unglücklich, weil ich die Artikelnummer auf keinen Fall ändern darf …

Ich forsche weiter und würde mich über Anregungen freuen.

Viele Grüße
Hermann

: Hermann KUFFNER

die Artikel sind so konzipiert, dass sie eine aut. generierte
eindeutige ID (longint, per Trigger vergeben) erhalten, außerdem
haben sie aber noch eine sogenannte Artikelnummer (alpha für den
Firmenkatalog), die ebenfalls eindeutig und indiziert ist, aber
manuell eingepflegt wird.
Die Relation läuft natürlich auf Basis der aut. ID.

Das würde ich ändern, so arbeiten Sie ja für Ihr Geld.

  • Autoincrement für das ID-Feld

Vorher die höchste Nummer suchen und mit SET DATABASE PARAMETER den Counter für diese Tabelle auf den gefundenen Wert+1 setzen.

Dann ist der Ärger mit dem Trigger weg.