Nya huvudböcker från Exact Online dyker upp först efter en vecka i glaccountsincremental (Invantive Cloud → SQL Server)

Frågor (nl)
,
1

Vad jag stöter på

Vi kopierar data från Exact Online till en SQL-databas med hjälp av applikationsmodulen i Invantive Cloud, där vi använder PSQL för att läsa in data från tabellen GLAccountsIncremental. Synkroniseringen körs dagligen, men nya huvudbokskonton (General Ledger) dyker först upp i vår SQL-databas efter ungefär en vecka.

Konkret exempel

Nyligen skapades nya huvudbokskonton den 29 januari. Den 5 februari fanns dessa fortfarande inte i vår SQL-databas, trots att synkroniseringen körs dagligen. Även efter att ha kört synkroniseringen manuellt laddades dessa rader inte in.
När posterna till slut väl laddas in ser vi i kolumnen Created att det angivna datumet är det korrekta skapandedatumet (29 januari).

Vad jag redan har provat

  • Kontrollerat att den dagliga körningen av applikationsmodulen lyckas.
  • Kört kopieringsprocessen manuellt igen.
  • Kontrollerat om filter eller datumbegränsningar i våra PSQL-skript eventuellt utesluter data.

Inget av detta gav någon förklaring till varför nya rader först blir tillgängliga efter ungefär en vecka.

Fråga

Hur kan det komma sig att nya rader i GLAccountsIncremental blir tillgängliga så sent?
Finns det eventuellt en inställning i Invantive Cloud eller Exact Online som avgör när denna tabell uppdateras eller synkroniseras?

2

I grunden är UniversalSQL-drivrutinen för Exact Online i realtid.

Det finns dock cachar; dessa kan konfigureras för Invantive Cloud-databaser enligt beskrivningen i:

Dessa värden används normalt inte i Invantive App Online eftersom cacharna är avstängda där.

De kan också styras via set-satser som:

set use-http-disk-cache ...

och

set use-http-memory-cache ...

Se även:

3

Tack för ert snabba svar!

Cachen var inställd på 57600 (16 timmar), vilket jag nu har sänkt till 3600 (1 timme). Men jag tycker ändå att det är konstigt att det tar mer än en vecka innan de nya raderna laddas in. Vad skulle det kunna bero på?

4

En cacheinställning på 16 timmar kan inte vara orsaken.

Orsaken måste då ligga någonstans i logiken och/eller frekvensen av anrop.

Rådet är att kontrollera koden för set och SQL-tips /*+ ... */.

5

Nej, jag har ingen uppsättning SQL-hintar i koden. Kan det bero på att det är en Incremental-tabell? Finns det andra ställen där man kan hitta cachar förutom http disk och bridge response?

image

6

En inkrementell tabell kommer att hämta ändringarna. Så länge Exact Online registrerar dem kommer ändringen att inkluderas.

Andra cachar som kan orsaka detta problem är inte kända.

Rådet är att göra problemet reproducerbart och analysera det med frågor i UniversalSQL-editorn.

7

Den här frågan har stängts automatiskt efter 1 vecka av inaktivitet. Det senast givna svaret har markerats som lösning.

Vänligen ställ en ny fråga i ett separat ämne om problemet uppstår igen. Inkludera gärna en länk till det här ämnet i den nya frågan genom att klistra in dess URL i texten.