Via delegatie is het probleem bekeken.
Eerste query:
select user_id
, datum
, sum(duration) duration
from ( select user_id
, trunc(date) datum
, duration
from TimeTracking54Weeks
)
group
by user_id
, datum
order
by datum desc
levert ruim 10.000 rijen, waarvan de meest recente betrekking heeft op 13-10-2023.
Tweede query:
select user_id
, datum
, sum(duration/60) duration
from ( select user_id
, trunc(started_on) datum
, duration
from timetracking
where started_on > trunc(sysdate) - 54*7
)
group
by user_id
, datum
order
by datum desc
levert ruim 1.000 rijen, waarvan de meest recente betrekking heeft op 10-10-2023.
Een nadere analyse via V2 vanaf 2 dagen terug met:
select /*+ http_memory_cache(false) */ *
from timetracking(started_after => trunc(sysdate) - 2)
levert 14 rijen op: 8 op 9 oktober, 4 op 10 oktober en 2 op 11 oktober.
Een nadere analyse via V1 levert via:
select tey.*
from teamleader.v1.timetracking_entries(trunc(sysdate) - 2, trunc(sysdate) - 2 + 7) tey
als resultaat 58 rijen: 24 op 9 oktober, 28 op 10 oktober, 4 op 11 oktober, 1 op 12 oktober en 1 op 13 oktober.
De query:
select id
, url
, parameter_list
, bytes_received
, bytes_sent
from sessionios@datadictionary
where id >= 18
order
BY id desc
toont hoe de API’s benaderd zijn:
waarbij de V1 API beduidend meer data teruggeeft.
Hieruit blijkt dat de aanroepen technisch correct zijn, maar dat de V1 API beduidend meer rijen teruggeeft voor een minstens zo breed datumbereik.
Advies is om dit probleem bij Teamleader Support aan te kaarten.
Mocht er gevraagd worden naar nog gedetailleerdere logging van de API-calls, dan zijn die te achterhalen via het Invantive Query Tool zoals beschreven in: