select t.*
from SnelStart.Grootboekmutaties.GrootboekMutaties t
where ([datum] > to_date('20400101', 'YYYYMMDD'))
limit 1
Het duurt ook eeuwig als ik in plaats van 2040 een recentere datum pak, bijvoorbeeld alleen boekingen over 2025 en later.
Als ik kijk naar de gegeneerde API-call op SnelStart via:
select id, url, duration_ms, execution_start_date_utc, execution_end_date_utc, successful, error_message
from sessionios@datadictionary
where data_container_alias='snr'
order
by id desc
Dit betreft blijkbaar een SnelStart-omgeving waarbij - zelfs bij meerdere pogingen - de SnelStart API-server niet in staat is om een antwoord te geven binnen 56 seconden. Na aantal pogingen zal Invantive UniversalSQL ook de handdoek in de ring gooien zonder enig resultaat, maar dit kan wel 10 minuten duren.
Er is gekeken of de pagina-omvang nog van invloed is, maar ook met een pagina-omvang van 10 rijen geeft de API-server geen antwoord.
Een mogelijk alternatief is of alles ophalen (maar dit is blijkbaar een grote SnelStart-omgeving) of een filter gebruiken op modifiedOn:
select t.*
from SnelStart.Grootboekmutaties.GrootboekMutaties t
where modifiedOn >= trunc(sysdateutc)
Die is in een paar seconden klaar.
Het grappige is dat een query op saldo ook eindeloos duurt, zelfs met totaal onrealistische waardes:
select t.*
from SnelStart.Grootboekmutaties.GrootboekMutaties t
where saldo >= 1e9
Blijkbaar kan de SnelStart API-server een aantal van deze filters niet verwerken in deze specifieke omgeving.
Advies is om hiervoor contact te zoeken met SnelStart. Mogelijk dat via aanpassingen of een sneller abonnement er nog mogelijkheden zijn.
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.
