Analyse
De foutmelding itgenbed003 is niet reproduceerbaar gebleken voor de aangeleverde testgebruiker door via Invantive Query Tool aan te melden op https://bridge-online.cloud:
select * from [salesinvoicelinesincremental@eol]
Na circa 18 minuten werden 3656 rijen gertourneerd, verspreid over 5 divisies. In totaal werden volgens het scherm “Sessie I/Os” 795 API-calls uitgevoerd hiervoor. Het aantal rijen is dan wel opvallend laag. De output bevatte geen rijen voor de eerste drie divisies, terwijl er wel API-calls voor werden uitgevoerd:
| Divisiecode | #API-calls | #Rijen Verwacht |
|---|---|---|
| 712.524 | 262 | 657.047 |
| 1.616.934 | 248 | 1.085.548 |
| 1.684.812 | 262 | 721.801 |
| 1.908.480 | 5 | 1.570 |
| 1.911.638 | 5 | 1.792 |
| 2.952.257 | 4 | 106 |
| 2.952.293 | 4 | 116 |
| 2.969.663 | 4 | 72 |
Oorzaak blijkt een bug in de Invantive Bridge Online driver voor het Invantive Query Tool, zie Query Tool Bridge Online driver detecteert niet als deel administraties faalt.
De data is wel daarna opgehaald, maar de itgenbed003 trad niet op. Het is echter goed mogelijk dat dit ontstaan is door een out-of-memory op de server.
Advies is om de filters te hanteren die passen bij het gegevensvolume. Een query zoals:
select t.*
from ExactOnlineREST.Incremental.SalesOrderLinesV2Incremental@eol t
where ([Modified] >= 01-05-2026 16:00:30 (datetime))
verwerkt alle rijen (in dit geval 2,3 miljoen rijen, 4,8 GB aan data) om enkele rijen op te halen omdat de *Incremental-tabellen volledig bijgewerkt moeten worden. Daarnaast wordt vrijwel elke vorm van caching omzeild door het gebruik van een glijdend tijdvenster.
Verbeteringen:
- Gebruik voor deelsets een andere tabel die server-side filtering op het gewenste veld ondersteunt (zie boven).
- Gebruik een filter dat gebruik van caches toestaat, dus bijvoorbeeld datum/tijd naar beneden afronden naar de daggrens in plaats van precies x dagen eerder.