Bestätigung aus einer zweiten Installation - JTL-Wawi 2.1.1, MS SQL Server 2025 Express (17.0.1000.7) auf einem separaten Rechner im lokalen Netz unter Windows 11, Wawi-Clients greifen über das Netz zu.
Deine Analyse trifft bei uns exakt zu. Zwei Belege, die hier im Thread noch nicht stehen und beim Nachvollziehen helfen können.
1. Die Wawi nennt den Index selbst. Beim Drucken erscheint unten rechts eine Benachrichtigung, wörtlich:
Fehlerhaft
Speichern: Eine Zeile mit doppeltem Schlüssel kann in das dbo.tFile-Objekt mit dem eindeutigen UX_dbo_tFile_iBlobIdentifier_INCL_FILTER-Index [...]
Das ist SQL-Server-Fehler 2601, unverändert durchgereicht. Die Meldung ist flüchtig: kein Windows-Toast, kein Eintrag in tErrorlog oder tDbErrorlog. Wer sie wegklickt, sieht nur noch, dass das Dokument fehlt.
2. Wie man sieht, wie oft es vergeblich versucht wurde. Gescheiterte INSERTs zählen die Identität trotzdem hoch. Die Lücke zwischen dem höchsten vergebenen Schlüssel und dem Identitätszähler entspricht also der Zahl der abgewiesenen Versuche:
Code:
SELECT COUNT(*) AS zeilen, MAX(kFile) AS hoechster_schluessel, IDENT_CURRENT('dbo.tFile') AS zaehler FROM dbo.tFile;
Liegt der Zähler über dem höchsten Schlüssel, ist die Differenz ein bequemes Maß für den Schaden - man muss die Rechnungen nicht einzeln durchgehen. Bei uns ist die Lücke deutlich, und sie wächst mit jedem Druckversuch weiter.
Unser Befund im Überblick: Die letzte gespeicherte Datei stammt vom Morgen des 15.09. - das ist genau die Zeile mit der Null-GUID. Ab der nächsten Rechnung, wenige Minuten später, wurde kein Dokument mehr abgelegt, und seither kein einziges. Zur Gegenprobe haben wir den Platz einmal freigeräumt (iBlobIdentifier der betroffenen Zeile auf NEWID gesetzt). Ergebnis:
genau eine Rechnung wird gespeichert, deren neue Zeile trägt sofort wieder die Null-GUID, die nächste scheitert. Der Client schreibt sie also bei jeder Rechnung, nicht nur einmal.
Zu tBild: Dort ist es dasselbe Muster mit anderer Folge. Bricht man einen hängenden Speichervorgang ab, bleibt eine tBild-Zeile mit iBlobIdentifier =
NULL zurück, unverknüpft. Wird dasselbe Bild später über die Ameise importiert, findet jtlBildList.FindByHash diese Zeile und der Deserialisierer stirbt mit einer NullReferenceException in Setter_iBlobIdentifier - die Spalte ist als nullable deklariert, wird aber nicht leer gelesen. Ein einziger solcher Datensatz legt den Bildimport dieses Bildes komplett lahm.
Danke für das Skript - wir warten vorerst auf den angekündigten Hotfix und drucken zwischenzeitlich in PDF.
