Fehler beim Speichern von Waren

[rainer.kohls@…]

Folgender Fehler tritt gerade ziemlich häufig beim Speichern von Waren auf. Nach verändern von bspw. der Lieferantenartikelnummer oder der Warengruppe wurde die Ware ab und zu gespeichert, manchmal auch nicht.
Wenn nicht, dann erschien diese Meldung:

INSERT INTO history_erp (trans_id, employee_id, addition, what_done, snumbers) VALUES (?, (SELECT id FROM employee WHERE login = ?), ?, ?, ?) (1145, rainer, SAVED, , partnumber_372)
FEHLER: doppelter Schlüsselwert verletzt Unique-Constraint »history_erp_pkey«

Hmm, normalerweise sollte sowas nicht passieren. Die history Tabelle vergibt ihre ids selber.

Wie sind denn die Ausgaben der folgenden SQL Abfragen auf der Datenbank:

SELECT nextval('id'::text);

Und

SELECT MAX(id) FROM history_erp;

SELECT nextval('id'::text);

Ausgabe: 1231

SELECT MAX(id) FROM history_erp;

Ausgabe: 2630

arrgh...Die Auswirkungen hab ich auch schon gesehen, alle Buchungen die ich eingegeben habe, wo der Fehler auftrat sind doppelt vorhanden. Hab natürlich nicht drauf geachtet, was das für ein Fehler sein könnte und nochmal bestätigt, dann ging es "meistens", aber scheinbar wurde auch mit Fehler schon gebucht....

Um wenigstens eine korrekte UstVA abgeben zu können, hab ich jetzt mal eine neue DB angelegt und die Daten mit dem "Jahresabschluß-Skript" aus dem Wiki übernommen, aber auch bei der Debitorenbuchung erscheint folgender Fehler:

INSERT INTO history_erp (trans_id, employee_id, addition, what_done, snumbers) VALUES (?, (SELECT id FROM employee WHERE login = ?), ?, ?, ?) (248, rainer2009_2, SAVED, Buchungsnummer = 248, ordnumber_)
FEHLER: doppelter Schlüsselwert verletzt Unique-Constraint »history_erp_pkey«

Ahjo, das was ich mir gedacht habe. Da hat es die Datenbank zerschossen.

Die id Sequenz wird vom Programm niemals angefasst, was auch immer das bewirkt hat, stammt nicht aus der Lx-Office ERP.

Evtl ein Drittprogramm auf der Datenbank unterwegs gewesen?

Nein ein Drittprogramm war gar nicht am Werk, das einzige was überhaupt noch die DB angefasst hat, war mein Sicherungsskript, aber das hat nur gelesen, nie geschrieben.

...Das einzige was mir noch so einfällt ist, das ich als ich die unstable mal getestet habe, diese DB auch hab aktualisieren lassen. Ich war zwar der Meinung das den moment nur Tabellen dazukamen,aber evtl. hätt ich das gleich lieber sein lassen sollen....wenn es denn überhaupt aus der Richtung kam.

Also ich hab jetzt nochmal geschaut ob die sequence evtl irgendwo gedropt und neu erstellt wurde, aber auch das nicht.

Schauen Sie doch bitte mal, welche Einträge mit den ids 1220-1230 vergeben wurden, das müsste ja dann zu der Zeit passiert sein, als es kaputt gegangen ist. Jede Kerntabelle in Lx-Office hat eine itime Spalte, die mit now() gefüllt wird.

wenn ich mir die ids anzeigen lasse, dann kann man den Fehler gut nachvollziehen. Was auch immer passiert ist, aber id 1220 hat das Datum 14.04.2007, während 1221 das Datum 25.10.2009 trägt und so setzt sich das munter fort. Die Einträge die aus 2007 stammen haben aber keine fortlaufende id, manchmal sind ganze Blöcke aus 2007, danach wieder ein paar 2009er dazwischen. Sieht für mich so aus, als ob seit ich vor einiger Zeit den Server neu aufgesetzt habe, die ids "irgendwie" wieder von worne anfangen zu zählen und dann ab und zu mal eine freie id abbekommen und ab und zu halt nicht.
Kann mir aber nicht wirklich erklären, warum das da angefangen hat, da ich dort auch einfach nur die Verzeichnisse übernommen habe und die db (fehlerlos) wieder zurückgesichert habe.

Ich denke ja fast, dass das nicht so einfach ist meine bestehende DB wieder gerade zu biegen...
Gibt es denn eine Möglichkeit, das ich eine neue DB anlege, so in der Art wie mit dem Jahresabschlußskript, wo die Rechnungen etc. rausfliegen, aber meine CRM-Daten etc. mitgenommen werden und der id-Zähler, bzw. die Historie zurückgesetzt wird?
Das würde mir schon sehr weiterhelfen

(In reply to comment #7)

Ich denke ja fast, dass das nicht so einfach ist meine bestehende DB wieder
gerade zu biegen...

Ich fürchte das ist korrekt.

Gibt es denn eine Möglichkeit, das ich eine neue DB anlege, so in der Art wie
mit dem Jahresabschlußskript, wo die Rechnungen etc. rausfliegen, aber meine
CRM-Daten etc. mitgenommen werden und der id-Zähler, bzw. die Historie
zurückgesetzt wird?
Das würde mir schon sehr weiterhelfen

Keine die ich so parat hätte, und ich würde es auch nicht empfehlen.

Wenn der Bruch wirklich erst am 25.10. passiert ist, würde ich eher zum Backup der vorigen Woche raten, und die verlorenen Tage nachtragen.

Wie ist der status dieses Bugs? Hat sich das wieder eingerenkt?

Status kann eigentlich auf fixed stehen, nachdem einspielen der Datensicherung von vor dem 25.10. sind zumindest keine Fehler mehr aufgetreten.
Vielen Dank nochmal
Grüße
rainer