Een van mijn databases bevat niet alle gegevens in de incremental tabel van transactionlines. De niet incremental variant bevat wel alle transacties.
De cutoff point is 31-12-2023, daarvoor zijn er geen gegevens. Hoe kan ik dit verhelpen?
Advies is om de analysestappen te volgen beschreven in:
Vermeld in een eventueel antwoord de uitkomsten van de analyse.
Ik vind het lastig om te zien wat er gebeurt. De timestamps kloppen en via Invantive SQL krijg ik de goede gegevens terug.
Toch krijg ik in Power BI niet de goede gegevens terug. Dit is wat ik in de Bridge Online Monitor zie:
- ExactOnlineREST.Incremental.TransactionLinesIncremental
- SQL-instructie
select t.* from ExactOnlineREST.Incremental.TransactionLinesIncremental@eol t where (([Date] >= :w1) and ([Date] <= :w2)) limit 1000
- Parameterwaarden
w1 = 31-12-2021 23:00:00 (datetime), w2 = 30-12-2023 23:00:00 (datetime)
- Rijen 0
Dit zouden in ieder geval meer dan 0 rijen moeten zijn.
Het lijkt ook alsof alles wordt teruggezet naar UTC tijd, want in power bi filter ik op #date(2022, 1, 1) en #date(2023,12,31) en deze worden in de parameters allebei een uurtje teruggezet.
De gebruikte SQL-engine is in beide producten gelijk qua versie. Er van uit gaande dat de data op Power BI niet uit cache komt (geen vinkje aan in Bridge Online Monitoring details) denk ik te begrijpen uit het antwoord dat de volgende query in de Invantive UniversalSQL-editor WEL resultaten teruggeeft en NIET via Bridge Online:
select t.*
from ExactOnlineREST.Incremental.TransactionLinesIncremental@eol t
where [Date] >= to_date('20220101')
and [Date] <= to_date('20231231')
limit 1000
Klopt het dat de data in Bridge Online niet uit cache komt?
Klopt het dat de bovenstaande query via Bridge Online GEEN rijen teruggeeft en WEL via de UniversalSQL-editor?
Dat klopt. Ik krijg via de UniversalSQL-editor wel resultaten terug en via de Bridge Online niet. Alle gegevens komen niet uit de cache.
Ik heb naast Power BI ook nog via Postman de gegevens proberen op te halen via Bridge Online en dat geeft hetzelfde resultaat.
Iets wat mij is opgevallen is wanneer ik een request doe met [Date] < 2024-01-01 ik een aantal rijen met Date 2023-31-01T00:00:00 terug krijg.
De filter query die hierbij hoort is $filter=Date ge 2022-01-01T00:00:00+01:00 and Date lt 2024-01-01T00:00:00+01:00.
Als ik echter een request doe met [Date] <= 2023-12-31 krijg ik helemaal niks terug.
De filter query die hierbij wordt gegenereerd is
$filter=Date ge 2022-01-01T00:00:00+01:00 and Date le 2023-12-31T00:00:00+01:00
Het lukt niet om het opvallende feit te interpreteren. De notatiewijze [Date] < 2024-01-01 is ons niet bekend.
Advies is om het SQL-statement tussen UniversalSQL-editor en Bridge Online vanuit Postman te vergelijken.
Kunnen beide statements toegevoegd worden?
De notatiewijze [Date] < 2024-01-01 is de notatiewijze uit Power Query. Dit is echter niet de kern van het probleem. De query in de UniversalSQL-editor en hetgeen dat ik in de Bridge Online Monitor zie is identiek, alleen de resultaten verschillen.
Er van uitgaande dat:
- de ontbrekende transacties niet specifiek op 1 uur betrekking hebbende,
- de queries beide luiden:
select t.*
from ExactOnlineREST.Incremental.TransactionLinesIncremental@eol t
where [Date] >= to_date('20220101')
and [Date] <= to_date('20231231')
- de UniversalSQL-editor wel de verwachte resultaten bevatten en Bridge Online niet,
is verzoek om een aanpassing te maken aan de datacontainer van de betrokken database.
Verzoek is om de volgende instellingen toe te voegen achter de connection string:
incremental-force-save-always=true
Deze instelling zorgt er voor dat altijd een nieuwe versie van de metadata wordt vastgelegd, ook als er geen mutaties zijn.
Gelieve daarna te wachten tot de cache van de database verlopen is (meestal maximaal 16 uur) en de data opnieuw via Bridge Online op te halen, in combinatie met een ophaling van:
IncrementalLoadStatusesIncrementalLoadStatisticsIncrementalLoadEventLogEntries
En deze drie tabellen als Excel op te slaan.
Gelieve deze Excel-werkboeken te mailen aan support@invantive.com onder vermelding van de URL van dit topic.
Met het toevoegen van incremental-force-save-always=true krijg ik de volgende foutemelding:
itgenpae003
Onbekend connectorattribuut 'incremental-force-save-always'.
Mogelijke geldige alternatieven: invantive-sql-forward-filters-to-data-containers, invantive-sql-shuffle-fetch-results-data-containers.
Dank voor het melden. Deze nieuwe functionaliteit bleek in deze toepassing nog niet te werken. Een nieuwe release is inmiddels hiervoor in productie genomen.
Gelieve nogmaals te proberen.
Gelieve daarna te wachten tot de cache van de database verlopen is (meestal maximaal 16 uur) en de data opnieuw via Bridge Online op te halen, in combinatie met een ophaling van:
IncrementalLoadStatusesIncrementalLoadStatisticsIncrementalLoadEventLogEntries
En deze drie tabellen als Excel op te slaan.
Gelieve deze Excel-werkboeken te mailen aan support@invantive.com onder vermelding van de URL van dit topic.
Ik heb het hiermee geprobeerd en de gegevens lijken nu weer te kloppen. Is het de bedoeling om incremental-force-save-always=true nu weer uit te zetten?
De instelling increment-force-save-always kan weer verwijderd worden; deze instelling dient enkel om te zorgen dat de tabellen IncrementalLoadStatus, IncrementalLoadStatistics en IncrementalLoadEventLogEntries altijd bijgewerkt worden, ook als er geen of weinig mutaties zijn.
Een vraag over tijden is afgesplitst naar:
Deze vraag is automatisch gesloten na 1 week inactiviteit. Het laatste gegeven antwoord is gemarkeerd als oplossing.
Gelieve een nieuwe vraag te stellen via een apart topic als het probleem opnieuw optreedt. Gelieve in de nieuwe vraag een link naar dit topic op te nemen door de URL er van in de tekst te plakken.
Er zijn redenen om aan te nemen dat administratie-eigenschappen intern gewijzigd worden door Exact in afwijking van de specificaties.
Om deze hypothese te onderbouwen/weerleggen zullen we voor delegatie via een ander kanaal contact opnemen.
Verdere informatie is te lezen in:
Dit topic is 3 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.