Ladda om TransactionLinesIncremental helt

Frågor (nl)
, ,
1

Sedan en kort tid tillbaka använder jag ExactOnlineREST.Incremental.TransactionLinesIncremental@eol via Invantive Bridge Online (OData4) i Excel/Power BI. Jag förväntade mig att efter den första fullständiga inläsningen skulle vid varje uppdatering endast delta hämtas och bearbetas: ändrade och borttagna rader sedan föregående gång. Det jag ser i loggningen avviker från detta. Jag undrar om detta är normalt beteende eller om något är fel.

Miljö

  • Invantive Bridge Online 26.0.286
  • Bokföring med cirka 170 000 rader för den inkrementella tabellen
  • HTTP disk cache 4 timmar, Bridge respons cache 15 minuter

Vad jag ser i IncrementalLoadEventLogEntries

  • Efter delta följer vid nästan varje uppdatering en återställning baserad på radantalet: “Full reload of incremental cache … since the current cache row count … deviates too much from the calculated allowed minimum row count …”. Därefter följer “Reconstructing. Do not reuse old data. Full reload…”.
  • Vid varje uppdatering står det "Timestamp moved from to " med tomma värden, och “No need to update incremental results since there was no previous version”.
  • Flera gånger: “Can’t find all data files for most recent download … Expecting 2 data files, found 0”.

Vad jag ser i Session I/O’s

  • Delta i sig verkar fungera bra: sync/Financial/TransactionLines?$filter=Timestamp gt …L med endast ändrade rader.
  • Därefter följer dock cirka 170 sidor med hela tabellen. Så länge disk cachen är giltig kommer de från cachen, men en uppdatering tar ändå 60 till 80 sekunder.
  • Deleted API frågas vid varje uppdatering från Timestamp gt 0L och gt 1L, vardera 4 sidor. Jag hade förväntat att även denna skulle starta från senaste observerade tidsstämpel.
  • Påföljande uppdateringar startar med samma Timestamp gt …L-värde. Tidsstämpeln verkar alltså inte uppdateras efter ett delta, vilket gör att delta ökar.
  • Om disk cachen har löpt ut hämtas den fullständiga inkrementella tabellen på nytt från Exact efter delta (cirka 220 faktiska anrop, över 3 till 8 minuter för endast denna tabell).

Mina observationer
Före delta matchar den sparade kopian exakt $count. Efter bearbetning av de drygt 3 000 borttagna ID:n från Deleted API är det cirka 3 000 rader färre. Det verkar som att ID:n som rapporteras som borttagna fortfarande existerar i Exact, vilket orsakar att radkontroll till slut resulterar i en fullständig omladdning. Men kanske tolkar jag detta fel.

Mina frågor

  1. Är det normalt att hela tabellen rekonstrueras efter varje delta?
  2. Är det normalt att Deleted API alltid läses från tidsstämpel 0 och att senaste observerade tidsstämpel inte uppdateras?
  3. Är min misstanke om de borttagna ID:n korrekt, eller finns det någon annan förklaring till det avvikande radantalet?
  4. Kan detta vara relaterat till det som nämndes i detta ämne om release 26.0 angående inkrementella filer?

Om detta inte är det förväntade beteendet: hur kan jag lösa det, så att endast delta bearbetas?

Jag kan skicka exportfiler från händelselogg och Session I/O på begäran.

2

Det går inte helt att förstå den eventuellt AI-genererade texten.

Att ladda om helt är i alla fall inte normalt beteende. Detta händer bara om algoritmen anser att datasetet är ofullständigt.

Tusentals borttagna rader är inte heller vanligt.

Rådet är att lägga till en skärmdump av en sådan omladdningsbegäran som beskrivs nedan.

Kompletterande information

Är det möjligt att lägga till en (anonymiserad) skärmdump av begärandets detaljer i Online Monitoring på Invantive Cloud som beskrivs i Meer inzicht met nieuwe Online Monitoring?

Du hittar detaljerna genom att klicka på nedladdningsbegäran som representerar ämnet för detta ämne.

Nedladdningsförfrågan har vanligtvis ett SQL-uttryck där tabellnamnet är synligt.

Se till att åtminstone följande uppgifter är synliga från båda kolumnerna:

  • titelraden med förfrågnings-ID,
  • statuskod, nätverksstorlek, väg och tidspunkter i den vänstra kolumnen,
  • felkod och felmeddelande längst ner i den vänstra kolumnen,
  • hela den högra kolumnen inklusive SQL-uttryck, tabellnamn och parametervärden.

Till exempel:

image
image1474×640 49.6 KB

Kontrollera rätt server och användare

Kontrollera noggrant att du loggar in på Invantive Cloud-webbplatsen med samma användarnamn som du bearbetar data med, till exempel via Invantive Bridge Online. Du kan bara se förfrågningar från den Invantive Cloud-användare som du loggar in med på webbplatsen.

Kontrollera rätt begäran och detaljer

Se till att du först väljer begäran för att visa detaljerna. Det bör bara finnas en begäran synlig i skärmbilden.

Kontrollera också noggrant om begäran har en väg med odata4, apps eller mcp. Förfrågningar med andra vägar är generellt inte relevanta för detta ändamål.

Felmeddelande och tips via e-post

Dessutom kommer Invantive Cloud-användaren som fått felmeddelandet till sin e-postadress ofta få ett e-postmeddelande med ett felmeddelande och tips ifall det är ett felmeddelande i Power BI, Power Query, Azure Data Factory, Qlik eller Tableau.

Rådet är att kontrollera skräpposten för den berörda användaren för sådana e-postmeddelanden som skickats från support@invantive.eu.