Results count of getLeadChanges is less than the remainingCount returned by last request

[Anonymous]

Hi all,

I have 7163 records in ActivityRecord. And when I call getLeadChanges() to get the results, I would request for 8 times.
The returnedCount&remainingCount pair would be 1000&6163,1000&5163,1000&4163,1000&3163,1000&2163,1000&1163, and 1000&163 for the front 7 times.
Then I think I should get 163 records and the remainingCount would be 0 for the last request. But the result is that I get 106 records and the remainingCount is 0.
So I get 7106 records instead of the expecting 7163.

When I retry this feature, I still get 1000&6163 for the first request.
What's happened to my data?
Any suggestions?

Thanks,
Biao

[Anonymous]

Hi Rick,

Thank you for your suggestion. But I need the hard count before getting all records down.

I'm not sure whether I have met the case a greater-than-0 remainingCount with nothing more to return. But I would not have an infinate loop because I would break it when I get the result that returnCount is 0. So, just one more request is OK.

Thanks,
Biao

[Rick_Bergen]

Biao, if you read all the records until there are none, that should be a good count.

Regarding inaccurate remainingCounts, can I assume if the returnCount is less than the batch size then that there is nothing more to return?  Is there a better way to avoid being in an infinate loop of looking for more records when there are none?

I'm finding the remainingCount is greater than 0 even though there is nothing more to return when searching by email for a LeadRecord and that email is also a SFDC username.  Odd, huh?

[Anonymous]

OK, I get it. Thank you very much, Kenny.

But I need the count number now in my integration. So, which API should I use for getting the definitive number?
What's your suggestion about this issue?
BTW, how about the remainingCount of getMultipleLeads()? Is that also a fuzzy count?

Thanks,
Biao

[Kenny_Elkington · Accepted solution]

Hey Biao,

For performance reasons remainingCount is a fuzzy count and not a hard count.  It's suggested that you interpret a nonzero remainingCount to indicate that there is more data which can be retrieved, and not a definitive count of the number of records which can be.