Ik loop tegen volgende probleem aan bij Exact Online omgeving:
SalesInvoiceLinesIncremental geeft alleen regels terug tot 28 februari. Terwijl daarna nog gefactureerd is. In SalesInvoiceBulk zit wél facturen tot en met gisteren.
Als ik rechten in Exact Online bekijk lijk ik alles nog steeds te hebben:
Wat heb ik al geprobeerd:
Is hier een oplossing voor?
In onderstaande screenshots is te zien dat er wél facturen zijn t/m gisteren maar géén factuurregels:
select *
from ExactOnlineREST.SalesInvoice.SalesInvoicesBulK@eol
order by invoicedate desc
limit 5000
Meest recente zijn van 12 april 2024.
select *
from ExactOnlineREST.SalesInvoice.SalesInvoicesBulK@eol
order by invoicedate desc
limit 5000
Meest recente zijn van 28 februari 2024 (onafhankelijk of regelnummer 0 of ander regelnummer).
Er zijn via *Bulk 28 facturen in de afgelopen zeven dagen:
select InvoiceId
from SalesInvoicesBulk@eol
where invoicedate > trunc(sysdateutc) - 7
Ook bevatten de facturen rijen, zoals drie bij deze InvoiceId:
select *
from SalesInvoiceLinesBulk@eol
where InvoiceId = to_guid('0740cad5-59e9-403a-98dc-3982ac314bdd')
Een ophaling via SalesInvoiceLinesIncremental geeft 28 facturen in de afgelopen zeven dagen:
select count(*)
from SalesInvoiceLinesIncremental@eol
where invoicedate > trunc(sysdateutc) - 7
and linenumber = 0
Advies is om eerst vast te stellen of Data Replicator de data langer cachet dan gewenst. En om daarna te kijken of de cachelaag van de *Incremental-tabellen dit veroorzaakt. Het is niet mogelijk om dat van buitenaf te doen.
Beide onderwerpen worden uitgebreid behandeld in:
Bij gebruik zonder Invantive Data Replicator van:
select /* ods(false) */ * from ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol
where created > sysdate - 7
komt er 0 uit.
De volgende query laat zien dat er wel om nieuwe data gevraagd wordt:
select SUCCESSFUL
, PARTITION
, BYTES_RECEIVED
, substr(replace(URL, 'https://start.exactonline.nl/api/v1/2383427/sync/SalesInvoice/SalesInvoices', ''), 1, 60)
from sessionios@datadictionary
where id > 248
order by id desc
met als resultaat:
Blijkbaar komt er geen nieuwe data van na Timestamp 14831002885.
“Last seen timestamp” in IncrementalLoadStatuses@eol is 14.831.002.885.
Echter, op een andere PC met lege caches is deze waarde 11001767382.
Het vreemde is dat de administratie blijkbaar op 28 maart verplaatst is tussen Exact Online-servers zoals blijkt uit:
select DivisionMoveDate from systemdivisions@eol
-- 2024-03-28 00:24:27
Dit komt ook terug in de Incremental-loadlogging:
--
-- This is the timestamp (last division move date) of the
-- division in format YYYYMMDDHH24MISS.
--
select distinct TimestampEnvironment
from incrementalloadstatuses@eol
where TimestampEnvironment != 'never'
// 20240328002427
Blijkbaar had de oude server een timestamp/rowversion van circa 14831002885, terwijl de nieuwe rond de 11001767382 zit.
Het Invantive-algoritme voor *Incremental-tabellen voorziet in het verplaatsen tussen Exact Online-servers. In dat geval moet in de IncrementalLoadLogEntries een regel verschijnen met code itgeneor253. Deze is echter niet aangetroffen.
Tussentijds zijn de inc- en http-mappen in %USERPROFILE%\invantive\cache wel leeggemaakt, maar zonder soelaas.
De inc- en http-mappen in %USERPROFILE%\invantive\cache zijn in samenspraak opnieuw leeggemaakt, en toen werkte het weer, hetzij met Timestamp-waardes in de reeks rond 11001767382.
Het is niet te reproduceren waarom omstreeks 28 maart het algoritme de caches niet automatisch zoals gecodeerd heeft geleegd.
Helaas treden verhuizingen tussen Exact Online-servers zelden op. Een zoektocht over alle omgevingen heen leidde tot niet 1 verplaatsing binnen 4 weken. Zekerheidshalve worden de analyse-instructies boven genoemd uitgebreid met een controle op de timestamp.
Daarnaast zal de laatste serververhuizing een nieuw veld worden in SystemPartitions@DataDictionary vanaf relesae 24.0.141.
Het probleem lijkt nu inderdaad te zijn opgelost.
Ik ben minder technisch onderlegd op dit gebied dan de support medewerkers van Invantive, maar voor iemand die dit probleem ervaart zou ik de volgende actie aanraden:
Gooi de hele cache van de betreffende datacontainer leeg en draai dan opnieuw.
Met dank aan intensief analyse en oplossing van Invantive.
Toevallig komt vandaag omhoog bij een andere gebruiker dat zijn administraties verplaatst zijn “vanwege beheertechnische redenen” naar een andere database in de nacht van 4 op 5 maart.
Mogelijkerwijs is dat ook hier gebeurt.
Is het mogelijk om dat na te kijken bij Mijn Exact Online (rechtsboven) → Mijn Exact Communicatie?
Dit topic is 7 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.
Onpraktisch voor analyses is dat de inhoud van IncrementalLoadStatuses, IncrementalLoadStatistics en IncrementalLoadEventLogEntries niet altijd bijgewerkt worden. Als er weinig wijzigingen zijn in een tabel, dan kan gedurende maximaal een week de inhoud niet bijgewerkt worden. De *Incremental-tabel wordt dan voor het laatste stukje telkens opnieuw opgebouwd, hetgeen goedkoper is dan een volledige reconstructie.
Voor meer gemak gedurende de analyse zijn een drietal instellingen toegevoegd aan de Exact Online-driver:
incremental-force-save-always: altijd vastleggen nieuwe versie, ook als er geen verschillen zijnincremental-skip-save-max-age-hours: maximaal aantal uren om opslaan over te slaan (standaard 1)incremental-skip-save-max-changed-rows: maximaal aantal mutaties om opslaan over te slaan (standaard 500)Deze instellingen zijn instelbaar via set.
De nieuwe instellingen zijn beschikbaar vanaf release 24.0.153.
Specifiek voor incrementele-tabellen lijkt er sprake van problemen binnen Exact Online zelf. Verdere berichten op: