Voor een klant van mij loop ik er tegenaan dat niet alle boekingen in de tabel TransactionLinesIncremental van Exact Online terugkomen. Zie ondderstaande boekstuknummers:
Dit gaat om transacties in de periode van 18 februari 2023 tm 24 maart 2023.
Er zijn geen bekende problemen over het ontbreken van transacties die veroorzaakt worden door bugs in Invantive SQL / Invantive Cloud. Er is enige maanden geleden wel een bug geweest door een afwijking tussen de Exact Online-specificaties en realisatie van de inhoud, maar een workaround hiervoor is reeds lange tijd in productie.
Mocht daar toch een vermoeden voor zijn, gelieve dan informatie in een antwoord toe te voegen:
- Een Invantive SQL-statement dat de divisie, transactienummer, regelnummer, en aanmaak- en bijwerkdatum toont bij uitvoering via Invantive Cloud SQL Editor. Gebruik een filter om de data hoeveelheid te beperken tot hetgeen hoort bij het derde punt. Als startpunt kan de SQL uit Bridge Online Monitoring gebruikt worden.
- De uitvoer hiervan in de SQL Editor als CSV of tabel.
- Een (geanonimiseerde) afdruk uit Exact Online waar in dezelfde divisie andere transacties zichtbaar zijn die ontbreken in bovenstaande.
Op basis van deze informatie kunnen gericht conclusies of vervolgvragen gesteld worden.
Bij deze het gemaakte statement in SQL:
select *
from ExactOnlineREST.Incremental.TransactionLinesIncremental@eol
where EntryNumber > 20230348
and EntryNumber < 20230578
In Invantive cloud krijgen we wel de transacties te zien maar in Power BI-desktop via de Invantive Bridge Online niet.
Bij deze stuur ik ook de Power BI statement:
let
Transactionlines = let
Transactionlines = [
Source = OData.Feed("https://bridge-online.cloud/acme/odata4", null, [Implementation="2.0"]),
#"ExactOnlineREST.Incremental.TransactionLinesIncremental@eol_table" = Source{[Name="ExactOnlineREST.Incremental.TransactionLinesIncremental@eol",Signature="table"]}[Data]]
in
Transactionlines[Source],
#"Filtered Rows" = Table.SelectRows(Transactionlines, each ([Name] = "ExactOnlineREST.FinancialTransaction.TransactionLines@eol" or [Name] = "ExactOnlineREST.FinancialTransaction.TransactionLinesBulk@eol" or [Name] = "ExactOnlineREST.Incremental.TransactionLinesIncremental@eol" or [Name] = "ExactOnlineREST.Sync.SyncTransactionLines@eol" or [Name] = "ExactOnlineXML.XML.GLTransactionLines@eol" or [Name] = "ExactOnlineXML.XML.GLTransactionLinesEx@eol")),
#"ExactOnlineREST Incremental TransactionLinesIncremental@eol_table" = #"Filtered Rows"{[Name="ExactOnlineREST.Incremental.TransactionLinesIncremental@eol",Signature="table"]}[Data],
#"Filtered Rows1" = Table.SelectRows(#"ExactOnlineREST Incremental TransactionLinesIncremental@eol_table", each [Division] = 123456),
#"Filtered Rows2" = Table.SelectRows(#"Filtered Rows1", each [Date] > #datetimezone(2018, 12, 31, 0, 0, 0, 1, 0))
in
#"Filtered Rows2"
In de bijlage heb ik de anonieme Invantive Bridge Online-output toegevoegd en de Exact online transacties (van enkel de omzet grootboekrekening, dus er zijn nog meer missende transacties).
Dank voor de informatie. De bijlages zijn niet doorgekomen omdat die uit beveiligingsoverwegingen onderdrukt worden, maar de beschikbare informatie is waarschijnlijk voldoende.
Op Invantive Cloud komen wel de juiste rijen terug. Een belangrijk verschil is dat Invantive Bridge Online een extra cachelaag gebruikt. Die kan ingesteld worden zoals beschreven op Differentieer OData4 cachegedrag met Power BI.
Advies is om dit artikel te lezen en de cache-instellingen te vergelijken met de bedrijfswensen.
Daarnaast kan het nodig zijn om de cache te resetten. Dit is feitelijk een “fail”; het bewust resetten doordat de data fout is hoort niet nodig te zijn, de onder-de-motorkap logica van de Exact Online SQL-driver moet automatisch de juiste gegevens achterhalen op basis van de daadwerkelijke werking van de Exact Online sync-API’s.
Het resetten moet gebeuren op Bridge Online zelf zoals beschreven op:
Mocht het probleem na uitvoering van bovenstaande twee adviezen terugkomen, gelieve dan een antwoord toe te voegen. Op basis van toegang via te verstrekken delegatie zal dan eventueel verder gezocht worden.
Ik heb het cache geheugen gewist alleen ik blijf de transacties missen in OData-feed.
Graag verleen ik de delegatie zodat jullie het verdere probleem kunnen onderzoeken. Zouden jullie mij hier over willen mailen zodat er geen vertrouwelijke gegevens op het forum terecht komen? Alvast bedankt!
Zou er iemand mij hiermee kunnen helpen? Alvast bedankt!
Het wissen van de Bridge Online-cache leidde niet tot andere uitkomsten en ook in de SQL-editor van Invantive Cloud met zijn eigen cache geeft ook de verwachte resultaten. Dit sluit niet uit dat er in de Power BI-query een foutje zit.
Zekerheidshalve het verzoek om een EntryNumber te kiezen dat WEL resultaten geeft en een die er geen geeft en dan de volgende drie SQL queries uit te voeren in Invantive Cloud en de daarop volgende drie via de Bridge Online URL. In totaal levert dit 12 meetpunten op met een aantal rijen: “SQL Query 1 - bestaat”, “SQL Query 1 - bestaat niet”, etc.
Vervang “INVULLEN” door het EntryNumber en Division in alle queries.
Vervang “URLSEGMENT” door het Bridge Online URL-segment van de database.
Gelieve de resulterende 12 meetpunten met label toe te voegen als antwoord.
SQL Query 1
select count(*)
from ExactOnlineREST.TransactionLines
where EntryNumber = INVULLEN
and Division = INVULLEN
SQL Query 2
select count(*)
from ExactOnlineREST.TransactionLinesBulk
where EntryNumber = INVULLEN
and Division = INVULLEN
SQL Query 3
select count(*)
from TransactionLinesIncremental
where EntryNumber = INVULLEN
and Division = INVULLEN
OData Query 1
https://bridge-online.cloud/URLSEGMENT/odata4/ExactOnlineREST.FinancialTransaction.TransactionLines@eol?$filter=EntryNumber%20eq%20INVULLEN%20and%20Division%20eq%20INVULLEN
OData Query 2
https://bridge-online.cloud/URLSEGMENT/odata4/ExactOnlineREST.FinancialTransaction.TransactionLinesBulk@eol?$filter=EntryNumber%20eq%20INVULLEN%20and%20Division%20eq%20INVULLEN
OData Query 3
https://bridge-online.cloud/URLSEGMENT/odata4/ExactOnlineREST.Incremental.TransactionLinesIncremental@eol?$filter=EntryNumber%20eq%20INVULLEN%20and%20Division%20eq%20INVULLEN
Wij hebben de analyse uitgevoerd met de verschillende query’s. Als we het op precies dezelfde manier doen, zit er geen verschil tussen invantive en wat we in Power BI ophalen en lijkt het goed te gaan.
Waar een verschil ontstaat is op het moment dat we de hele tabel ophalen en geen directe filters meegeven op een entrynummer.
Dit verschil is te zien bij “OData query 1 - bestaat niet”.
Dit moet eigenlijk niet kunnen dat daar een verschil in zit; we halen dezelfde tabel op maar geven geen filters mee. Dan zouden de regels die als we wel filters meegeven er toch in moeten zitten in de gehele opgehaalde tabel?
Zelf gebruiken wij de incrementel tabel. Als ik entrynummer 20230416 filter in de tabellink, zoals bij de analyse dan haal ik 4 regels op.
Haal ik heel de tabel op zonder filtering dan is dit entrynummer niet meer te zien. Hierdoor ontbreken er dus heel veel regels.
Daarnaast ben ik achter het volgende gekomen.
Er zit een verschil tussen de incremental (ExactOnlineREST.Incremental.TransactionLinesIncremental@eol) en de normale (ExactOnlineREST.FinancialTransaction.TransactionLines@eol) tabel.
Filter ik heel februari bij de incremental tabel dan krijg ik 111 regels.
Filter ik heel februari bij de normale tabel dan krijg ik 1664 regels.
Beide tabellen bevatten geen filters. De incremental tabel en de normale tabel hebben wel het hetzelfde aantal regels, maar er gaat dus iets mis bij de inhoud.
Kunnen jullie verklaren waarom de incremental tabel qua inhoud verschilt met de normale tabel?
Wij vernemen graag jullie reactie en hopen dat dit snel opgelost kan worden.
Gebruikte entry nummer en division:
Bestaat niet in Power BI en wel in Invantive:
- Entry nummer: 20230416
- Division: 1861032
Bestaat zowel in Power BI als in invantive:
- Entry nummer: 20230621
- Division: 1861032
SQL Query 1 – bestaat niet:
select count(*) from ExactOnlineREST.TransactionLines where EntryNumber = 20230416 and Division = 1861032
4
OData Query 1 – bestaat niet:
https://bridge-online.cloud/7c5b8d84-16a0-49bb-b4e7-3a9a73df59ff/odata4
Als ik in Power BI de hele tabel importeer via volgende link haal ik maar 2 regels op voor entrynummer 20230416 (dan filter ik in power bi in de hele geimporteerde tabel het entrynummer eruit):
Result: 2 regels
Als ik direct in de hele link de filters toepas en echt alleen entrynummer 202301416 ophaal dan krijg ik 4 regels. Met onderstaande link:
Resultaat: 4 regels
Waarom zit hier een verschil in? Is letterlijk dezelfde tabel maar dan met filter erop. Moet hetzelfde resultaat geven.
SQL Query 1 – bestaat
select count(*) from ExactOnlineREST.TransactionLines where EntryNumber = 20230416 and Division = 1861032
Resultaat: 3 regels
Odata Query 1 – bestaat
SQL Query 2 – bestaat niet
select count(*) from ExactOnlineREST.TransactionLinesBulk where EntryNumber = 20230416 and Division = 1861032
Resultaat: 4 regels
OData Query 2 – bestaat niet:
SQL Query 2 – bestaat
select count(*) from ExactOnlineREST.TransactionLinesBulk where EntryNumber = 20230621 and Division = 1861032
Resultaat 3 regels
OData Query 2 – bestaat:
SQL Query 3 – bestaat niet
select count(*) from TransactionLinesIncremental where EntryNumber = 20230416 and Division = 1861032
Resultaat: 4 regels
OData Query 3 – bestaat niet:
Resultaat 4 regels
SQL Query 3 – bestaat
select count(*) from TransactionLinesIncremental where EntryNumber = 20230621 and Division = 1861032
Resultaat: 3 regels
OData Query 3 – bestaat:
Hallo,
Hebben jullie een update over het bovenstaande?
Een analyse is uitgevoerd. Het is niet gelukt om de antwoorden op de vragen accuraat te interpreteren, ondanks pogingen om de tekst te herformatteren naar een leesbaar formaat.
Het betreft twee administraties met de volgende verdeling vanuit de Invantive Cloud SQL Editor:
select division
, count(*)
from transactionlinesincremental
group
by division
| Division | Count |
|---|---|
| 1861032 | 127035 |
| 2575738 | 2764 |
Na inperking tot de echte regels met:
select division
, count(*)
from transactionlinesincremental
where linenumber between 1 and 9000
group
by division
levert dit op:
| Division | Count |
|---|---|
| 1861032 | 84659 |
| 2575738 | 2443 |
De aantallen rijen van 111 via *Incremental en 1664 via TransactionLines zijn niet te reproduceren via:
select division
, count(*)
from transactionlinesincremental
where financialperiod = 2
and financialyear = 2023
group
by division
dat als resultaat heeft:
| Division | Count |
|---|---|
| 1861032 | 2078 |
| 2575738 | 57 |
Een query op de oude TransactionLines met:
select division
, count(*)
from transactionlines
where financialperiod = 2
and financialyear = 2023
group
by division
levert op:
| Division | Count |
|---|---|
| 1861032 | 2078 |
| 2575738 | 57 |
Beide queries bevatten een regelnummer 0 en 9999. Het aantal boekstukken in februari 2023 is hiermee, respectievelijk, 391 en 5.
Vraag: wordt met “februari” bedoeld “februari 2023”?
Een onderzoek naar boekstuk 20230416 levert via SQL Editor op Invantive Cloud 4 regels op via:
select *
from ( select *
from transactionlinesincremental
)
where entrynumber = 20230416
and division = 1861032
En net zo veel regels via:
select *
from ( select *
from exactonlinerest..transactionlines
)
where entrynumber = 20230416
and division = 1861032
Vraag: wordt met “Invantive” in “Bestaat niet in Power BI en wel in Invantive” bedoeld: “de SQL-editor van Invantive Cloud”?
Bij opvraging in Google Chrome via de Bridge Online URL https://bridge-online.cloud/7c5b8d84-16a0-49bb-b4e7-3a9a73df59ff/odata4/ExactOnlineREST.Incremental.TransactionLinesIncremental@eol?%24filter=EntryNumber%20eq%2020230416%20and%20Division%20eq%201861032 komen vier rijen terug.
De volgende query levert ook vier rijen op in Google Chrome: https://bridge-online.cloud/7c5b8d84-16a0-49bb-b4e7-3a9a73df59ff/odata4/ExactOnlineREST.FinancialTransaction.TransactionLines@eol?%24filter=EntryNumber%20eq%2020230416%20and%20Division%20eq%201861032 (evenals https://bridge-online-beta.invantive.com/7c5b8d84-16a0-49bb-b4e7-3a9a73df59ff/odata4/ExactOnlineREST.FinancialTransaction.TransactionLines@eol?%24filter=EntryNumber%20eq%2020230416%20and%20Division%20eq%201861032).
Het lukt niet om het gesignaleerde probleem te bevestigen.
Advies is om een meer nauwkeurig reproductiescenario aan te leveren of om via een kort consult ondersteuning te zoeken.
Is het mogelijk om morgen middag of donderdag ochtend via Teamviewer een half uur te meeten, zodat we de casus helder uit kunnen leggen?
Advies is om een reproductiescenario te maken waarbij een verschil zichtbaar is door het uitvoeren van twee verschillende OData4-URL’s terwijl die wel gelijk resultaat moeten leveren.
Deze OData4-URL’s zijn te vinden bij de details van een verzoek in Bridge Online Monitoring.
Dit sluit andere factoren uit omdat hiermee de payload direct komende vanaf Invantive Bridge Online bekeken wordt.
Meer informatie over de werking is te vinden in:
- Limit Data load from Simplicate on Invantive Cloud to Azure Data Factory
- OData4 query options of Invantive Bridge Online
- Differentiate OData4 for Power BI Cache Behavior
- OData downloads herleiden naar Power BI data sets
- Differentieer OData4 cachegedrag met Power BI
- Snellere OData downloads met kleinere omvang met kleine aanpassing in Power BI
- How to filter data from OData query on Azure Data Factory?
De volgende resultaten krijgen wij als we in de url meteen de transactiefilter toevoegen op de transactionlines endpoint:
Geval 1: Vier regels bij ExactOnlineREST.FinancialTransaction.TransactionLines met OData filter
Hierin zien wij 4 regels en dit zijn ook de regels die wij verwachten.
Geval 2: Twee regels bij ExactOnlineREST.FinancialTransaction.TransactionLines met client-side filter
De volgende resultaten krijgen wij als we de hele tabel ophalen en deze vervolgens filteren:
https://bridge-online.cloud/ACME/odata4/ExactOnlineREST.FinancialTransaction.TransactionLines@eol
Filter op EntryNumber=20230416
Hierin zien wij nog maar twee regels terwijl wij vier regels verwachten.
Geval 3: Geen regels bij ExactOnlineREST.FinancialTransaction.TransactionLinesIncremental
De volgende resultaten krijgen we als we de transactionlinesincremental volledig ophalen en deze vervolgens filteren:
Hierin zien wij nog maar geen regels terwijl wij vier regels verwachten.
Zouden jullie willen zorgen dat als de gehele tabel opgehaald wordt, dat dan wel alle 4 de transacties terugkomen in plaats van dat deze verdwijnen?
Vanuit de klant hoorde ik dat inmiddels naast de data van Februari en Maart er ook data in januari omzet begint te missen. Zijn er eventueel aanknopingspunten waar wij bij kunnen helpen?
Ik ben benieuwd.
Hallo heren/dames,
Is er een update over het bovenstaande?
Ik ben benieuwd.
Advies is om bij geval 3 de HTTP-statuscode te controleren. De tabel ExactOnlineREST.FinancialTransaction.TransactionLinesIncremental@eol bestaat niet; wel bestaat deze tabelnaam in het Incremental-schema (zie TransactionLinesIncremental: Exact Online Transactieregels (Incrementeel) - Exact Online API Data Model).
Merk op dat het downloaden relatief lang duurt om het een Free Exact Online Plan betreft; deze kent 1 parallel downloadkanaal.
Geval 1
Bij geval 1 komen inderdaad vier regelnummers retour in de browser: 0, 1, 2 en 9999.
Het SQL-statement in Invantive Bridge Online Monitoring is:
select t.*
from ExactOnlineREST.FinancialTransaction.TransactionLines@eol t
where ([EntryNumber] = :w1)
met w1: 20230416
De data is opgeslagen als geval1.json (12 kB) en vervolgens gecontroleerd via:
select jte.*
from read_file_text@Os('C:\temp\forums3468\geval1.json') rft
join jsontable
( 'value[*]'
passing rft.file_contents
columns EntryNumber int64 path 'EntryNumber'
, LineNumber int16 path 'LineNumber'
) jte
where jte.EntryNumber = 20230416
order
by jte.LineNumber
met als resultaat:
Geval 2
Bij geval 2 worden initieel eerst alle transactieregels gedownload via:
curl --output c:\temp\geval2.json --user vimak@favoreclame.nl:Q0i9h@7uiI6GDAorsgmq https://bridge-online.cloud/7c5b8d84-16a0-49bb-b4e7-3a9a73df59ff/odata4/ExactOnlineREST.FinancialTransaction.TransactionLines@eol
Het SQL-statement in Invantive Bridge Online Monitoring is:
select t.*
from ExactOnlineREST.FinancialTransaction.TransactionLines@eol t
De data is opgeslagen als geval2.json (373.870 kB) en vervolgens gecontroleerd via:
select jte.*
from read_file_text@Os('C:\temp\forums3468\geval2.json') rft
join jsontable
( 'value[*]'
passing rft.file_contents
columns EntryNumber int64 path 'EntryNumber'
, LineNumber int16 path 'LineNumber'
) jte
where jte.EntryNumber = 20230416
order
by jte.LineNumber
met als resultaat enkel regels 0 en 2:
Geval 3
Bij geval 3 is met de gecorrigeerde URL de download uitgevoerd: .../odata4/ExactOnlineREST.Incremental.TransactionLinesIncremental@eol via:
curl --output geval3metcorrectie.json --user john.doe@acme.com:secret https://bridge-online.cloud/ACME/odata4/ExactOnlineREST.Incremental.TransactionLinesIncremental@eol
Het SQL-statement in Invantive Bridge Online Monitoring is:
select t.*
from ExactOnlineREST.Incremental.TransactionLinesIncremental@eol t
De data is opgeslagen als geval3metcorrectie.json (177.780 kB) en vervolgens gecontroleerd via:
select jte.*
from read_file_text@Os('C:\temp\forums3468\geval3metcorrectie.json') rft
join jsontable
( 'value[*]'
passing rft.file_contents
columns EntryNumber int64 path 'EntryNumber'
, LineNumber int16 path 'LineNumber'
) jte
where jte.EntryNumber = 20230416
order
by jte.LineNumber
Deze query leidt tot nul regels.
Analyse
Analyse 1: volledigheid en consistentie
Als eerste stap is gekeken naar volledigheid en consistentie. De volgende statistieken zijn opgevraagd met onderliggende SQL:
| Geval | #Rijen | #LineNumber = 0 | #LineNumber = 1 | #LineNumber = 9999 |
|---|---|---|---|---|
| 1 | 4 | 1 | 1 | 1 |
| 2 | 130621 | 17100 | 22775 | 15394 |
| 3 | 130621 | 16904 | 22590 | 15146 |
De verwachting is dat de laatste LineNumber 0 en 9999-kolommen grofweg dezelfde waardes bevatten. Dit geldt alleen voor geval 1.
Ter verdieping is in lijn met Schatten omvang Exact Online administratie een server-side telling uitgevoerd van de data in Exact Online. Het aantal rijen was:
| Divisiecode | Rijen |
|---|---|
| 2575738 | 2793 |
| 1861032 | 127828 |
| Totaal | 130621 |
Het positieve is dat 130621 aansluit bij de tweede kolom van de eerste tabel bij analyse 1. Echter, het is bijzonder vreemd dat regelnummer 0, 1 en 9999 een verschillende distributie hebben.
Vervolgens is de JSON geanalyseerd voor het aantal transacties overall en per LineNumber 0, 1, 2 en 9999. De getallen bij #LineNumber = 0 en #LineNumber = 9999 zouden grofweg gelijk moeten zijn, en met regelnummer 1 in de buurt. Later is ook #LineNumber is null toegevoegd omdat dat als onverwachte uitkomst er uit kwam.
| Geval | #Overall | #LineNumber=0 | #LineNumber=1 | #LineNumber=2 | #LineNumber=9999 | #LineNumber is null |
|---|---|---|---|---|---|---|
| 1 | 1 | 1 | 1 | 0 | 1 | 0 |
| 2 | 25058 | 17013 | 19988 | 6130 | 15306 | 3 |
| 3 | 19218 | 16845 | 19191 | 5688 | 15072 | 3 |
Het voorkomen van LineNumber is null is uitzonderlijk. Historisch werd - leek het - in de API’s het regelnummer berekend i.p.v. ruw doorgegeven, waardoor regels soms een andere volgorde kregen. Een jaar of 6 geleden is hierin tenminste een verbetering doorgevoerd, maar het ontbreken van een LineNumber leidt tot per definitie tot problemen in de uitkomsten. Het is dan niet bekend of een regel een kopregel of BTW-regel is, anders dan uit de context van andere velden (zie ook Bijzondere regelnummers zoals 9999 op financiële transacties in Exact Online).
De transacties met een boeking zonder regelnummer zijn zowel in geval 2 als in geval 3: 16900002, 17900033, 18900066. Uit controle blijkt dat dit resultaatboekingen zijn over de jaren 2016, 2017 en 2018. Een controle tegen een aantal andere administraties die nog in gebruik zijn leert dat dit voor die administraties ook geldt: in de jaren 2009…2015 zijn er een aantal boekingen voor BTW en resultaat zonder regelnummer. Blijkbaar is dit probleem niet in 2016 gecorrigeerd, maar in 2019 lijkt het.
Het probleem met LineNumber is null vervalt hiermee.
Blijft het probleem met de afwijkende aantallen boekstukken per regelnummer, terwijl het totaal wel sluit qua aantal boekstukregels.
Vervolgens is de scope uitgebreid met twee gevallen: TransactionLinesBulk (geval 4) en SyncTransactionLines (geval 5), in eerste instantie via enkele SQL-queries.
Metingen met rijen geven:
| Geval | #Rijen | #LineNumber = 0 | #LineNumber = 1 | #LineNumber = 9999 |
|---|---|---|---|---|
| 1 (OData4) | 4 | 1 | 1 | 1 |
| 2 (OData4) | 130621 | 17100 | 22775 | 15394 |
| 3 (OData4) | 130621 | 16904 | 22590 | 15146 |
| 4 (SQL) | 130621 | 22503 | 29627 | 20128 |
| 5 (SQL) | 130621 | 22503 | 29627 | 20128 |
Vervolgens zijn de metingen uitgebreid met ook gevallen 1, 2 en 3 via SQL uit te voeren en geval 4 en 5 via OData4:
| Geval | #Rijen | #LineNumber = 0 | #LineNumber = 1 | #LineNumber = 9999 |
|---|---|---|---|---|
| 1 (OData4) | 4 | 1 | 1 | 1 |
| 1 (SQL) | 4 | 1 | 1 | 1 |
| 2 (OData4) | 130621 | 17100 | 22775 | 15394 |
| 2 (SQL) | itgeneor229 | itgeneor229 | itgeneor229 | itgeneor229 |
| 3 (OData4) | 130621 | 16904 | 22590 | 15146 |
| 3 (SQL) | 130621 | 22503 | 29627 | 20128 |
| 4 (SQL) | 130621 | 22503 | 29627 | 20128 |
| 5 (SQL) | 130621 | 22503 | 29627 | 20128 |
Hierbij valt het op dat de uitkomsten bij verwerking met SQL en OData4/JSON anders zijn voor geval 3.
Vervolgens is een analyse gemaakt van de meeste voorkomende omschrijvingen. Hierbij kwam naar voren dat het abonnement geen downloads groter dan 100.000 rijen toestaat (deze controle wordt momenteel niet uitgevoerd bij de SQL Editor van Invantive Cloud):
| Omschrijving | Aantal |
|---|---|
| invantive.com | 15.212 |
| itgenboe115 TOO MANY | 15.189 |
| Prijs ex. BTW | 10.410 |
| … |
De foutcode itgenboe115 (evenals itgenboe116, itgenboe114, itgenboe294 en itgenboe295) geeft aan dat de regel betrekking heeft op rij boven de 100.000.
Vervolgens is gekeken wat de EntryNumber en LineNumber zijn van deze gevallen. Hierbij bleek dat deze volledig ontbreken. Bij controle blijkt dit gewenst gedrag te zijn. Als er meer gedownload wordt dan het abonnement toestaat, dan worden deze velden leeggemaakt indien het datatype dat toestaat.
Eindconclusie is dat het gedrag verklaarbaar is doordat er meer gedownload wordt dan het abonnement toestaat.
Advies is om het abonnement te upgraden van het Free Exact Online Plan naar Invantive Office for Entrepreneurs.
In de programmatuur zijn een aantal verbeteringen uitgevoerd om deze analyse onnodig te maken:
- De lijst met stappen onderaan bij elk requestdetails toont
itgenboe375enitgenboe376indien er voor demo-, licentie- of anonymisatie-doeleinden gegevens gewijzigd zijn. - De datawijziging voor licentiebeperking is aangepast zodat er meer duidelijk herkenbare punten zijn, zoals de GUID “CA5B2B7F-7D93-49CB-BE8A-716A78C1D692” en “90C55B00-AD37-404D-A0FC-A3B0F2CACB71”.
Gebruikte SQL
Gebruikte SQL:
select count(*)
from read_file_text@Os('FILENAME.json') rft
join jsontable
( 'value[*]'
passing rft.file_contents
columns EntryNumber int64 path 'EntryNumber'
, LineNumber int16 path 'LineNumber'
) jte
select jte.LineNumber
, count(*)
from read_file_text@Os('FILENAME.json') rft
join jsontable
( 'value[*]'
passing rft.file_contents
columns EntryNumber int64 path 'EntryNumber'
, LineNumber int16 path 'LineNumber'
) jte
where jte.LineNumber in (0, 1, 9999)
group
by jte.LineNumber
order
by LineNumber
--
-- Tel rijen.
--
create or replace table countqueries@inmemorystorage
as
select ste.name
, sdn.label
, sdn.code
, replace(ODATA_SERVICE_URL_FOR_SELECT, '{division}', sdn.code) || '/$count'
url
, ste.name || ' @ ' || sdn.label
orig_system_group
from SystemDivisions@eol sdn
join SYSTEMTABLES@DataDictionary ste
on ste.PROVIDER_NAME = 'ExactOnlineAll'
and ste.CATALOG = 'ExactOnlineREST'
and ste.schema = 'Sync'
and ste.name = 'SyncTransactionLines'
--
-- Stuur de API-verzoeken zonder verdere interpretatie door als een
-- "Native Scalar Request". De resultaten worden vastgelegd in
-- dezelfde tabel "NativePlatformScalarRequest".
--
-- Er wordt gebruik gemaakt van XML-output. JSON wordt verkregen
-- door Content-Type in te stellen.
--
insert into exactonlinerest..nativeplatformscalarrequests@eol
( url
, orig_system_group
, fail_on_error
)
select url
, orig_system_group
--
-- Vervang door false als je niet overal rechten op hebt en true
-- als je dat wel zeker hebt.
-- Tabellen waar de huidige Exact Online gebruiker geen rechten
-- op heeft worden bij false stilletjes overgeslagen.
--
, false
from COUNTQUERIES@InMemoryStorage
--
-- Per tabel en administratie het aantal rijen.
--
select orig_system_group
, RESULT_TEXT
from exactonlinerest..NATIVEPLATFORMSCALARREQUESTS@eol
where SUCCESSFUL = 'Y'
and orig_system_group is not null
select jte.Description
, count(*)
from read_file_text@Os('C:\temp\forums3468\geval2.json') rft
join jsontable
( 'value[*]'
passing rft.file_contents
columns EntryNumber int64 path 'EntryNumber'
, LineNumber int16 path 'LineNumber'
, Description varchar2 path 'Description'
) jte
group
by jte.Description
select jte.*
from read_file_text@Os('C:\temp\forums3468\geval2.json') rft
join jsontable
( 'value[*]'
passing rft.file_contents
columns EntryNumber int64 path 'EntryNumber'
, LineNumber int16 path 'LineNumber'
, Description varchar2 path 'Description'
) jte
where jte.Description like 'invantive%'
or jte.Description like 'itgenboe115%'