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
Är det normalt att hela tabellen rekonstrueras efter varje delta?
Är det normalt att Deleted API alltid läses från tidsstämpel 0 och att senaste observerade tidsstämpel inte uppdateras?
Är min misstanke om de borttagna ID:n korrekt, eller finns det någon annan förklaring till det avvikande radantalet?
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.
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.
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.
select ...
from ExactOnlineREST.Incremental.TransactionLinesIncremental@eol
where (Division = :w1 and ((([GLAccount = :w2 or [GLAccount] = :w3) or [GLOAccount] = :w4) or [GLAccount] = :w5))
Division: 3619926
Huvudbokskonton: fyra olika GUID’er
Synligt resultat: 4119 rader.
Behandlade: 175866 rader hämtades nyss från Exact Online API, 0 svarade från cache, med 181 API-anrop.
Varaktighet: 230 sekunder.
Valda partitioner: 2
Återladdningen av denna cache orsakas av en protokollversionuppgradering. Den gamla cachen byggdes enligt protokollversion 7 under release 26.0.286, medan data hämtades från release 26.0.334.
Den interna loggningen, som även kan framträda i revisionstabellerna, dokumenterar detta:
Found payload in unsupported HTTP disk cache format in file '/SOMEPATH/TransactionLinesIncremental/72070809c7b62ad341e7de06cb24e183.cache': protocol version 7 instead of 9, compressed True, encrypted True.
Detta är dock en engångsföreteelse och kan inte ha inträffat tidigare. Analyser visar också att en bugg uppstår vid bestämningen av “timestamp”. Beteendet är varken normalt eller önskat.
En buggfix kommer att genomföras för detta i den kommande release 27.0, och om möjligt även inkluderad i release 26.0.
Det finns en ny version tillgänglig som borde lösa detta problem. De nödvändiga ändringarna finns tillgängliga från och med version 26.0.340 och i alla framtida BETA-versioner.
Denna nya version har släppts/ska släppas i produktion på Invantive Cloud.
Den här frågan har automatiskt stängts efter 1 vecka av inaktivitet. Det senast inskickade svaret har markerats som lösning.
Om problemet uppstår igen, vänligen ställ en ny fråga i ett separat ämne. Inkludera gärna en länk till det här ämnet i den nya frågan genom att klistra in webbadressen i texten.
