Wir sehen in der SyncDeleted-API ungefähr 130.000 Einträge. Über 80 % beziehen sich auf Entitätstypen für Verkaufsaufträge. Sie reichen bis zum 6. Januar 2026 zurück.
Wie können wir dieses Volumen begrenzen?
Wir sehen in der SyncDeleted-API ungefähr 130.000 Einträge. Über 80 % beziehen sich auf Entitätstypen für Verkaufsaufträge. Sie reichen bis zum 6. Januar 2026 zurück.
Wie können wir dieses Volumen begrenzen?
Dies sind sehr viele gelöschte Verkaufsauftragszeilen.
Sechs Monate Geschichte ist sehr lang. Laut der Dokumentation auf Exact Online REST API - Reference documentation sollten es 2 Monate sein (früher 1 Monat):
Hinweis: Das Protokoll der gelöschten Datensätze wird 2 Monate lang gespeichert. Daten, die älter als 2 Monate sind, werden automatisch gelöscht und sind daher auch über die gelöschte API nicht mehr verfügbar.
Eine Überprüfung in einer eigenen Produktionsumgebung mit einer vergleichbaren Anzahl an Buchungen wurde durchgeführt. Diese enthält ebenfalls 6 Monate Historie, nämlich seit dem 2. Januar 2026, 23:26:30. Die folgende Abfrage ergab jedoch viel weniger Änderungen; die höchste Anzahl in einem Monat war 1809.
select EntityType
, d
, count(*) c
from ( select EntityType
, to_char(DeletedDate, 'YYYYMM') d
from SyncDeleted
)
group
by EntityType
, d
Empfehlung ist:
Die Menge der gelöschten Zeilen kann, aber muss nicht unbedingt eine Auswirkung auf die Funktionsweise der Invantive-Tabellen haben, doch dies erfordert eine weitere Untersuchung anhand der verwendeten Abfragen, um festzustellen, ob dies der Fall ist und welchen Umfang dies hat.
Wir erhielten als Antwort:
Vielen Dank für das Einreichen der Support-Anfrage. Wenn alte Transaktionen, die im Januar gelöscht wurden, immer noch in der Sync/deleted erscheinen, klingt das tatsächlich nach einem Fehler, den wir beheben müssen. Daten sollten maximal 2 Monate verfügbar sein.
Da ich dieses Problem bisher nicht von anderen Entwicklern gehört habe, könntest du einen Nachweis dafür liefern?
- HTTP-Anfrage + Antwortkörper + Erklärung, welche Daten von Januar sind?
- Datum + Uhrzeit des API-Aufrufs
- Erklärung, was genau diese Entitäten waren, waren es zum Beispiel Buchungszeilen von einer bestimmten Buchung? Wenn ja, was für eine Buchung? Damit ich sehen kann, ob ich ein bestimmtes Muster finde.
- Ist es alles auf einer Verwaltung? Oder habt ihr dies in mehreren Umgebungen?
Ich freue mich auf die Antwort! Danke!
Es wird empfohlen, die angeforderten Daten über Native Call Logging zu sammeln:
set log-native-calls-to-disk true
%USERPROFILE%\NativeCalls.Im Query Tool sieht das so aus:
Und im Ordner so:
Der Inhalt reicht einem Entwickler völlig aus, um eine Antwort auf die gestellten Fragen zu finden:
Diese Frage wurde automatisch nach 1 Woche Inaktivität geschlossen. Die zuletzt gegebene Antwort wurde als Lösung markiert.
Bitte stelle eine neue Frage in einem separaten Thema, falls das Problem erneut auftritt. Bitte füge in der neuen Frage einen Link zu diesem Thema ein, indem du die URL in den Text einfügst.
Ab der Version 26.0.300 wurde eine Überprüfung beim Aufbau der inkrementellen Tabellen eingeführt.
Wenn eine Exact Online-Umgebung gelöschte Zeilen enthält, die älter sind als die in den Spezifikationen vorgeschriebene Zeitspanne plus 7 Tage, wird die Verarbeitung mit der Fehlermeldung abgebrochen:
itgeneor878
Ein gelöschtes Element hat das Löschdatum ‘…’, aber die Spezifikation besagt, dass das älteste mögliche Datum ‘…’ sein sollte.
Diese Prüfung gewährleistet, dass die Spezifikationen mit der Realität übereinstimmen, um die Korrektheit der gesammelten Daten und die Leistung sicherzustellen.
Wir empfehlen, sich dann an den Exact Online Support zu wenden mit der Bitte, die Daten zu bereinigen und sie damit in Einklang mit den Spezifikationen zu bringen unter: