This content has been marked as final. Show 4 replies
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.
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?
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?
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.