Fog Creek Software
Discussion Board

Why limit the number of cases returned by a query

I've just raised Case Number 2014 in our database, but if I want to list all cases then FogBugz only returns the first 500.

Can you remove this limit in the next release of the product?  In the past I've made this request and received a reply from Joel along the lines of "five hundred defects is a lot for one project" and indeed it is, but then again for some of the projects I've worked on this is only the start!

Colin Potter
Wednesday, June 9, 2004

Whilst its true that in theory 500 is a lot, we've got automagic reporting in our web applications and as a consequence 1 error can generate an awful lot of emails which in turn results in a lot of errors in certain views.

Of course one does triage to kill the duplicates (and there's a feature request in for the system to help) - but there are times...

Wednesday, June 9, 2004

500 is a lot for a new, well designed, always refactored and maintained app.

it's a tiny number when you're maintaining a huge legacy system with a small number of programmers.. that's reality.

Jon Newton
Wednesday, June 9, 2004

Any more than 500 cases is a giant web page, and performance wise can slow down the server immensely.  If you need this functionality, you must realize that your filter could take a very long time to display.  You're always free to modify the code to make it 1000 or something else.

Michael H. Pryor
Fog Creek Software
Wednesday, June 9, 2004

It would be better if FogBugz had the maximum number of Cases returned as a configurable option under Admin functions.  500 isn't that many cases - at the moment we've got over 25 projects using this instance of the tool and it doesn't take many on each to get to 500.  As a Test Engineer I want to see all the bugs allocated to me in one view - on occasion - and having the option to set the maximum number would be good.

OK, we could modify the code, but the Software manager doesn't believe in that because of maintainability and support issues, we use the tool straight out of the box, and I can see the sense in that.

Can you consider making this a configurable option in future - the next - release?

Colin Potter
Wednesday, June 9, 2004

Anything large enough to be generating that many cases must also be large enough to subdivide into sections. Your developers should not really be looking at the entire list at once any way. It's too overwhelming.

They should be seeing them based on priority, project, area, or those that are assigned directly to them. If any one of those is too large, then perhaps it is time to separate the project into subprojects or add more developers.

Alternately, those case that you decide are never going to get fixed (too low priority, etc.) - close them. They are effectively dead any way.

Sean Ennis
Thursday, June 24, 2004

(I second everything Sean just said.)

Fog Creek Software
Monday, June 28, 2004

I second all of that too.  However it doesn't negate  the point that 500 cases is not the same as "all cases".

All = all
500 = 500

If you had a test that had an expected result of "returns all cases" and the actual result you got was 500, it would be a fail.

I suspect that most people are using FogBugz for small projects.  We're use FogBugz for big ones, and we're about to be using FogBugz for a much bigger one.

Now I will be tasking the project manager to divide the project sensibly, but it still doesn't get around the original problem.  Pleeeeeeese fix it!

Colin Potter
Wednesday, June 30, 2004

*  Recent Topics

*  Fog Creek Home