Itgenclr009 Microsoft.OData.Core.ODataException,Message=Invalid JSON. Unexpected end of input was found in JSON content

[wvk]

bij het opvragen van ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol ?$filter = Modified ge 2026-04-30T08:22:59.3327600Z

krijg ik deze foutmelding:

Failure happened on ‘Source’ side.
‘Type=Microsoft.OData.Core.ODataException,Message=Invalid JSON.
Unexpected end of input was found in JSON content.
Not all object and array scopes were closed.,Source=Microsoft.OData.Core,’

Dit gaat fout sinds 1 mei 2026, daarvoor werkte het goed, ik heb het vermoeden dat er een datacorruptie o.i.d. in die tabel zit? Wellicht kunnen jullie daar wat aan doen?

[forums]

Aanvullen informatie

Is het mogelijk om een (geanonimiseerde) schermafdruk van de details van het verzoek in Invantive Bridge Online Monitoring toe te voegen zoals beschreven in Meer inzicht met nieuwe Bridge Online Monitoring?

De details vindt u door te klikken op het downloadverzoek welke het onderwerp van dit onderwerp representeert.

Het downloadverzoek heeft meestal een SQL-statement waarin de tabelnaam zichtbaar is.

Gelieve tenminste de volgende gegevens zichtbaar te laten van beide kolommen:

• de titelbalk met de request ID,
• de statuscode, netwerkgrootte, pad en tijdstippen in de linkerkolom,
• de foutcode en foutmelding helemaal onderaan in de linkerkolom,
• de gehele rechterkolom inclusief het SQL statement, tabelnaam en parameterwaardes.

Bijvoorbeeld:

Controleer juiste server en gebruiker

Controleer zorgvuldig dat u zich aanmeldt op de Bridge Online-website die ook gebruikt wordt vanuit Power BI en met dezelfde gebruikersnaam. U ziet alleen de verzoeken van de Invantive Cloud-gebruiker waarmee u zich aanmeldt op de website.

Er zijn vier servers in gebruik:

• bridge-online.cloud
• app-online.cloud
• bridge-online.invantive.com
• app-online.invantive.com

De gebruikte server ziet u in uw script of broncode van rapportage.

Controleer juiste aanvraag en details

Zorg ervoor dat u het verzoek eerst selecteert om de details weer te geven. Er hoort maar één verzoek zichtbaar zijn in de schermafbeelding.

Controleer ook zorgvuldig of het verzoek een pad heeft met odata4 of apps. Verzoeken met andere paden zijn over het algemeen niet relevant voor dit doel.

Foutmelding en tips per e-mail

Daarnaast zal de Invantive Cloud-gebruiker die de foutmelding heeft op zijn e-mailadres veelal een e-mail ontvangen met een foutmelding en tips als er sprake is van een foutmelding in Power BI, Power Query, Azure Data Factory, Qlik of Tableau.

Advies is om de spam van de betrokken gebruiker te controleren op dergelijke e-mails verzonden vanaf support@invantive.com.

[wvk]

[forums]

De achterliggende foutmelding geregistreerd on 174057067 is bij request 0HNLB0E1VL1NC:00000001:

itgenclr009
An item with the same key has already been added.
Key: DeliverToAddress.
Er is een onbekende fout opgetreden.

Tabel: SalesInvoiceLinesIncremental@eol op 8 administraties.

Call stack:

at Invantive.Data.NamedArrayConverter.Read(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options)                                                                                                                                                                                                                                                                                     at System.Text.Json.Serialization.JsonCollectionConverter`2.OnTryRead(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options, ReadStack& state, TCollection& value)                                                                                                                                                                                                                    at System.Text.Json.Serialization.JsonConverter`1.ReadCore(Utf8JsonReader& reader, T& value, JsonSerializerOptions options, ReadStack& state)                                                                                                                                                                                                                                                             at System.Text.Json.Serialization.Metadata.JsonTypeInfo`1.ContinueDeserialize[TReadBufferState,TStream](TReadBufferState& bufferState, JsonReaderState& jsonReaderState, ReadStack& readStack, T& value)                                                                                                                                                                                                  at System.Text.Json.JsonSerializer.<DeserializeAsyncEnumerableCore>g__CreateAsyncEnumerableFromArray|104_0[T](Stream utf8Json, JsonTypeInfo`1 listTypeInfo, JsonReaderOptions readerOptions, CancellationToken cancellationToken)+MoveNext()                                                                                                                                                              at System.Text.Json.JsonSerializer.<DeserializeAsyncEnumerableCore>g__CreateAsyncEnumerableFromArray|104_0[T](Stream utf8Json, JsonTypeInfo`1 listTypeInfo, JsonReaderOptions readerOptions, CancellationToken cancellationToken)+System.Threading.Tasks.Sources.IValueTaskSource<System.Boolean>.GetResult()                                                                                             at System.Threading.Tasks.TaskAsyncEnumerableExtensions.ToBlockingEnumerable[T](IAsyncEnumerable`1 source, CancellationToken cancellationToken)+MoveNext()                                                                                                                                                                                                                                                at Invantive.Data.Providers.ExactOnline.ExactOnlineRestProvider.ReadIncrementalDataFromChunkedStream(GlobalState owner, ExecutionOptions executionOptions, SqlExecutionStep sqlExecutionStep, ChunkedDiskCacheStreamConfig config, JsonSerializerSettings serializerSettings, ObjectDefinition objectDefinition, String partitionCode, SharedResultSetObjects sharedResultSetObjects, NamedArrayPool namedArrayPool, SparseArrayPool sparseArrayPool)+MoveNext()                                                                                                                                                                                                                                                                                                                                                    at Invantive.Data.Providers.ExactOnline.ExactOnlineRestProvider.GetDataForAddedApplicationTableIncrementalLocked(GlobalState owner, ExecutionOptions executionOptions, SqlExecutionStep sqlExecutionStep, ObjectDefinition objectDefinition, QueryObject queryObject, JsonDatabaseColumnDefinitionCollection allFields, String partitionCode, ParameterList parameters, String serviceUrl, String serviceUrlSelectFields, Int32 entityTypeId, HashSet`1 selectFields, Boolean isReconstructing, List`1 eventLogEntriesFromPrevious, NamedArrayPool namedArrayPool, SparseArrayPool sparseArrayPool)+MoveNext()
   at Invantive.Data.GenericProvider.ClientSideFilterNamedArrayRows(GlobalState owner, ExecutionOptions executionOptions, IEnumerable`1 namedArrayRows, IColumnDefinitionCollection retrievedFields, Int32 requestedFieldCount, Dictionary`2 allToVisibleColumns, Dictionary`2 filters, NamedArrayPool namedArrayPool, SparseArrayPool sparseArrayPool)+MoveNext()
   at Invantive.Data.SqlUtility.ClientSideFilterSparseArrays(GlobalState owner, ExecutionOptions executionOptions, IProviderManager manager, DatabaseColumnDefinitionCollection fields, IEnumerable`1 rows, QueryObject queryObject)+MoveNext()
   at Invantive.Data.ParallelSelectManyEnumerator`2.Read(GlobalState owner, ExecutionOptions executionOptions, TSource source). Category itgenpmr022.

[wvk]

Kan of moet ik iets hiermee? Of is het nog in onderzoek? Ik begrijp dat er ergens een dubbele DeliverToAddres is?

[forums]

Een nieuwe release is vanochtend in productie genomen die meer analytische data verzamelt.

Kunt u de foutmelding nogmaals opwekken zodat beter achterhaald kan worden wat de achterliggende oorzaak is?

[wvk]

Dit is de foutmeldig op dit moment:

itgenbed003
Systeemfout.

Request ID: 0HNLC004IQRS9:00000001

[forums]

De foutmelding in het scherm Systeemberichten is:

itgenbed003
An element with the key ‘DeliverToAddress’ already exists in a dictionary of String and Object.
An item with the same key has already been added. Key: DeliverToAddress.

Overige instellingen:

• Context: itgennar014
• DeliverToAddress: db57391e-3ecb-4232-9f17-60e5c4a44429

Andere velden zijn onder andere:

Timestamp: 28382443
Created: 2023-09-26T17:33:01.02Z
Creator: 5ef52cd2-8498...4-7562749116ef
Currency: EUR
DeliverTo: 09c7807a-f13f...f-73d1f9566567
DeliverToContactPerson: 49922259-b124...e-9c6a97437986
DeliverToAddress: 883dd49e-15cc...8-1b5b762e7831
Division: 712524
DueDate: 2023-10-26T00:00:00Z
ID: 8e8cc4f3-21d4...d-21a110de854b
InvoiceID: feb22eca-e0cb...8-0aa90b0c778b
InvoiceTo: 09c7807a-f13f...f-73d1f9566567
InvoiceToContactPerson: 15cafff3-5c8b...5-061e3fb83c7b
Item: 394254c4-f1f5...7-80f196ba5727
LineNumber: 16

[forums]

De oorzaak is onbekend.

Advies is om aan te melden op de URL die gebruikt wordt zonder odata4/... en dan de cache te herstellen zoals beschreven in:

Differentieer OData4 cachegedrag met Power BI

Go to English version Met behulp van een OData4 feed op Invantive Cloud kunt u data ophalen van meer dan 70 (cloud) platformen met Power BI en Power Query. Invantive Cloud maakt gebruik van verschillende technieken om de betrouwbaarheid en prestaties van het ophalen van data in Power BI en Power Query te verbeteren. Deze optimalisatietechnieken zijn ook van toepassing op andere OData4 consumenten zoals https://access-odata.com. Zorg ervoor dat je de structuur van Invantive Cloud begrijpt alvor…

De eerste volledige laadactie zal dan aanmerkelijk langer duren door het opbouwen van de *Incremental-caches.

[wvk]

Wat is de complete URL zonder die odata4 is dat dan dit? https://bridge-online.cloud/*****/ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol

En als die cache reset, dan geldt dat voor alle tabellen denk ik? Dat kan in dit geval bij een grote Exact Online-administratie wel eens dagen gaan duren?

[forums]

De server voor het resetten van de cache is dan bereikbaar op:

https://bridge-online.cloud/

Het opbouwen duurt normaliter pakweg gemiddeld 2-5 seconden per 1.000 rijen. Soms sneller, soms langzamer afhankelijk van de omgevingsfactoren zoals de beschikbaar gestelde capaciteit. Bij parallel laden is de maximale doorvoersnelheid met op Exact Online normaliter 1.000 rijen per seconde op basis van de minuut rate limit.

De omvang kan vlot en eenvoudig bepaald worden zoals beschreven in:

Sneller schatten aantal rijen op Exact Online met de tabel "RowCounts"

De Invantive UniversalSQL-driver voor Exact Online biedt vanaf release 24.0.185 een nieuwe tabel RowCounts. Via deze tabel kan in relatief korte tijd van alle uitleesbare tabellen in de ExactOnlineREST-catalogus het precieze aantal rijen per tabel en per administratie opgevraagd worden. Het opvragen van het aantal rijen van vijf gemiddelde administraties kost circa 505 seconden voor in totaal 467 tabellen. Voor een enkele administratie is de duur circa 500 seconden voor hetzelfde aantal tabell…

[wvk]

Ik heb zojuist ‘cache resetten’ gedaan en vervolgens opnieuw deze tabel proberen te laden, maar de foutmelding komt na een paar minuten direct weer: itgenbed003.

[forums]

Via een andere weg zal contact opgenomen worden om directer toegang te kunnen krijgen.

[forums]

Algemeen punt 1 van aandacht voor divisie 1616934 is dat er time-outs optreden binnen Exact Online. Een API-verzoek geeft niet binnen 23 seconden antwoord zoals:

itgenoda324
Probeer het opnieuw wanneer het niet lukt om tekst van partitie ‘1616934’ op te halen na 23.013 ms met behulp van ‘https://start.exactonline.nl/api/v1/1616934/sync/SalesInvoice/SalesInvoices?$select=*’ van ‘ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental’.
Wacht voor 1.347 ms en probeer opnieuw.
Poging #1 van 10; bericht ID ‘9bd24ca5-a90e-4950-be49-33b9236241dc’.
Invantive.Basics.InvantiveSqlException:
itgenoda316:
De gegevens kunnen niet worden gedownload omdat de verbinding is verbroken voordat de resultaten werden geretourneerd.
Time-out is ingesteld op 23.000 ms.

Normaliter hoort dit binnen enkele seconden een antwoord te geven.

Dit probleem wordt via (beperkt) opnieuw proberen automatsich opgelost waar mogelijk, met een (potentieel) significante verlenging van de verwerkingsduur tot gevolg afhankelijk van de frequentie van optreden.

[forums]

Algemeen punt 2 van aandacht is het configureren van time-out in Azure Data Factory / Microsoft Fabric.

Enkele voorbeelden:

itgenboe312
De gegevensdownload werd geannuleerd na 10 minuten, 1 seconde, bijvoorbeeld doordat Azure Data Factory de download voortijdig beëindigde als gevolg van een time-out ingesteld in Azure Data Factory.
Optimaliseer uw query zoals beschreven op Overzicht van Power BI-technieken om prestaties en downloadtijd te verbeteren - invantive. Voer de query vervolgens opnieuw uit.

URL: ExactOnlineREST.CRM.AddressesBulk@eol?$filter = Modified ge 2026-05-01T16:00:30.3259182Z

Exact heeft er in 2022 voor gekozen om op de achterliggende bulk-API Addresses geen filter (meer) toe te staan op Modified om bij gebruikers het gebruik van de *Incremental-API’s te stimuleren.

Zie ook bijvoorbeeld:

• Exact Online Bulk endpoints (server-side filtering)
• Mandatory filtering on single and bulk endpoints where sync APIs are available

Gezien het korte tijdsbestek is waarschijnlijk het gebruik van ExactOnlineREST..Addresses vele malen sneller, aangezien hier wel een server-side filter mogelijk is op Modified, ondanks de pakweg 12x tragere downloadsnelheid.

Dit is controleerbaar aan de hand van:

select *
from   AddressesBulk@eol
where  Modified >= sysdateutc - 1/24

select url
from   SessionIOs@DataDictionary
where  call_safe_name = 'ExactOnlineREST.CRM.AddressesBulk'
order
by     id desc

select *
from   Addresses@eol
where  Modified >= sysdateutc - 1/24

select url
from   SessionIOs@DataDictionary
where  call_safe_name = 'ExactOnlineREST.CRM.Addresses'
order
by     id desc

Dit is ook vooraf te bepalen met deze query:

select table_name
,      name
,      can_filter_server_side
,      influences_insert
from   SystemTableColumns@DataDictionary
where  name = 'Modified'
and    table_name in ('Addresses', 'AddressesBulk')
and    table_catalog_name = 'ExactOnlineREST'

De resultaten met en zonder server-side filtering zijn identiek, alleen het aantal API-calls kan sterk varieren.

[forums]

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.

[wvk]

@forums

select *
from   AddressesBulk@eol
where  Modified >= sysdateutc - 1/24

Bedankt voor het uitzoeken. Mijn concrete vraag op dit moment is: hoe kunnen we het beste de SalesInvoiceLines van Exact Online laden. We gebruiken nu het endpoint ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol met een ?$filter = Modified ge 2026-05-01T08:58:05.0990782Z.

Maar ook ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol?$filter = Timestamp gt 71760700 faalt met dezelfde systeemfout. Of moet ik nog op een ander veld filteren. Of wellicht overstappen op een ander endpoint?

De query

select timestamp, id, modified
from   ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol
where  Timestamp > 71760700 

geeft ook een systeemfout.

Eigenlijk is mijn vraag, op welke manier kan ik heb beste de SalesInvoiceLines laden vanuit Invantive? Zowel eerste keer (veel data) als incrementeel?

[forums]

Kunt u per statement specifiek aangeven welke foutmelding u krijgt met foutcode?

[wvk]

bovenstaande foutmelding komt als ik deze sql query uitvoer:

select count(*)
from ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol
where Modified > ‘2026-05-01T08:58:05.0990782Z’

Doe ik het met odata in adf dan krijg ik
Failure happened on ‘Source’ side.
‘Type=Microsoft.OData.Core.ODataException,Message=Invalid JSON.
Unexpected end of input was found in JSON content.
Not all object and array scopes were closed.,Source=Microsoft.OData.Core,’

[forums]

Deze foutmelding treedt op binnen Invantive Cloud; het betreft een out-of-memory doordat de maximaal beschikbare ruimte wordt overschreden.

Is het mogelijk dit ook te proberen via Invantive Bridge Online? De limieten liggen daar hoger.