Ontbrekende (afgeleide) velden in Exact Online Incremental/Sync tabellen
Een terechte vraag en ook eentje die terugkomt zoals blijkt uit Kolom CostCenterDescription kan niet worden gevonden in TransactionLinesIncremental - 2 van forums.
Er zijn geen plannen om deze kolommen toe te voegen aan de tabellen. Ze zijn bewust verwijderd, ook al staan ze om onduidelijke redenen wel bij de Sync API’s opgevoerd.
De oplossing is inderdaad om de benodigde veldwaardes te vinden door een join te leggen vanuit bijvoorbeeld ItemID
in een transactietabel naar ItemsIncremental
, en voor de artikelgroep vanuit ItemsIncremental
naar ItemGroups
. De laatste kent geen *Incremental
versie, maar is dusdanig klein en statisch dat hij rustig 1x per dag volledig bijgewerkt kan worden.
Waarom afgeleide velden achterwege laten
De structuur van Exact Online is dat er een aantal servers met SQL Server zijn met daarop de tabellen. Er liggen relaties tussen tabellen, zoals bijvoorbeeld tussen artikelen en artikelgroepen.
De inhoud van de tabellen is logisch gepartitioneerd per divisie en een ondernemer staat op dezelfde server als zijn accountant zoals blijkt uit het veld DivisionMoveDate
.
De *Incremental
tabellen zijn gebaseerd op de Sync API’s en de Deleted API van Exact Online en verbergen veel logica onder de motorkap zoals bijvoorbeeld rekening houden met het omhangen van ondernemers naar een andere accountant, mogelijk op een andere SQL Server.
De Sync API’s vormen een 1-op-1 reflectie van de inhoud van de achterliggende tabel en - ongelukkigerwijze - ook met de dan geldende waarde van velden uit andere tabellen door foreign key relaties af te lopen. De sync API tabellen kunnen alleen gefilterd op oplopende Timestamp
waarde opgevraagd worden.
Indien een gebruiker of een proces gegevens muteert in een tabel (toevoegen, veranderen of verwijderen), dan wordt (blijkbaar) in de tabel een veld gezet met de waarde van een monotoon stijgende teller, de Timestamp
. Deze teller nummert per SQL Server onafhankelijk op.
De waarde van Timestamp
geeft dus aan wanneer 1 of meerdere van de velden in de tabel gewijzigd zijn. Als de omschrijving van een artikel wijzigt, dan wijzigt ook de waarde van de Timestamp
.
De waarde van de Timestamp
in de tabel en de Sync API verandert niet als een waarde van een veld in een ander tabel verandert. Als bijvoorbeeld de omschrijving van een artikelgroep wijzigt, dan wijzigt niet de waarde van de Timestamp
in de artikelentabel.
Daarom is het essentieel om de waardes van afgeleide velden uit de Sync API tabellen achterwege te laten. Anders hangt het van het gebruikte filter op Timestamp
, het ophaalmoment en eventuele mutatiemomenten in de gerelateerde tabellen af welke waardes terugkomen voor afgeleide velden en zichtbaar worden in de cumulatie van wijzigingen in een *Incremental
tabel.
De theoretische achtergrond van dit probleem wordt uitgebreid behandeld in de verzamelingenleer en meer specifiek in het proces van databasenormalisatie.