Is there a limit to the number of IDs you are allowed to list within a filter

[LaurensKr1]

Hi,

I am working on a project level report and listed 163 projects ids as part of the report filter to get data from these projects. But it seems the report only recognized 100 ids from this filter I used text mode to achieve this.

Is there a limit to the number of items (or in this case ids) we are allowed to list within a report filter?

[skyehansen · Accepted solution]

I am tempted to say that if you post the filter, we can maybe help to troubleshoot -- but I totally understand that perhaps posting a blob of 163 IDs into a post is not the best thing in the world for people's inboxes, LOL.

So I will just say, if this happened to me, I would actually look to troubleshoot by first looking for typos (maybe some tabs missing? or otherwise messed up?), and then isolating some of the IDs that did not show up and searching for them in the system.

I've listed way more than 163 IDs in the past, and have never had an issue, but as you know, things change all the time.

[LaurensKr1]

Hi Skye,

Essentially I am using the below within a journal entry report:
project:projectID=ID1,ID2,ID3, etc.

project:projectID_Mod=in

And I agree, 163 IDs should not be an issue .. but for some reason it only pulls 100IDs in, not even in a specific order. I was considering the idea that maybe 63 projects did not have any status changes to display, but from the 63 not visible in the report, I am able to view them individually (meaning instead of 163 IDs, I took samples from the ones not listed as output from the 163).

And that is the answer. Well that was an interesting one. 

[skyehansen]

that's weird that it even works using the commas. I always separate my IDs with "tab" spaces. For example, you can copy and paste that string into Microsoft Word, and then do a search and replace for the comma with the special character dropdown in Word and substitute a tab in its place.

I'm not aware of any particular restrictions with journal entry reports. If you're able to see status changes in a journal entry report separately with the other 63 projects, I would run two tests -- one using tabs instead of commas to separate, and one where you split the project ID list in half and run two reports, each with half the list.

If the first option works, then don't use commas in the future. If the second option works, then at least we know there's a limitation in journal entry reports. (honestly, I only ever do this in regular project/task/issue-type reports)

[Doug_Den_Hoed__AtAppStore]

Hi @skyehansen,

Just a quick attestation that I too observed and was surprised by the (newer) comma vs (older) tab behavior about six months ago. At the time, I suspected it was an attempt to standardize on an easier to use (and possibly already established elsewhere within Adobe) convention for the (then upcoming) Filter builder. I'm now remembering that the commas concerned me because they tripped up the retrieval of the definitions via the API...but since Tabs also worked, continue to, and don't trip up the API, we've stayed with them, and all still seems well for now.

Regards,

Doug

[skyehansen]

thanks for the reminder Doug. I do remember seeing commas in the "new View UI" but dismissed it as a passing fad at the time. I don't observe a lot of it, so had completely forgotten it was a thing until now.