A default search of content server returns 10 pages of 20 items giving a maximum of 200 results. The 20 items per page is set by a variable called ResultCount. Developers usually try to work around the issue by setting the ResultCount as high as possible... but it is also capped at 200 items. Administrators try to increase this ceiling by setting various configuration parameters but ultimately these are hard limits and increasing them will degrade server performance. These tricks are trying to solve the wrong problem.
When someone does a Google search and gets a million results, do they need all of them? Nope. Does Google display all of them on one page? Of course not. It uses pagination to break the results into readable pages, usually 10 per page. Most people don't go past the first three pages. In fact, most people don't go past the first page. They're looking for anything that resembles their query so they just click the first link that might do. I guess someone at Stellent used that reasoning to decide that 10 pages of 20 items was ample enough. But content management is a bit different because the user is looking for something specific. They might try browsing through more than the first three pages, or even ten pages... but are they really going to browse through a million items? Probably not. Just like Google, UCM doesn't need to return all the results at once. It just needs to let you navigate through more of the result pages.
The secret to UCM's unlimited search results is that only the built-in pagination gets capped at 200 items - so just ignore the pagination and calculate your own.
UCM uses values for
ResultCount(number of items per page) and
StartRow(the item to start pagination from) to build a page of results. You can see these values in the URL. Just change the StartRow to, say, 401 to get a page with search results for items 401 to 420. This is the way to access any 20 items from an unlimited amount of results.
To recalculate the pagination, there's the
TotalRowsvariables. Use all four variables with a bit of maths and you'll have your own unlimited pagination to cycle through Dynamic Lists. You can then write a simple component to replace the Content Server pagination with your unlimited pagination.
A side-effect of unlimited pagination is improved user behaviour. Previously they just chucked in a simple (or empty) query, moaned about browsing limitations and gave up. But once a user can go beyond 200 items they quickly realise that endlessly browsing results is a waste of time. Instead they invest their time in refining their queries. Ultimately this improves their usage and confidence of the system. Just like Google does.