I would add to the discussion my observation that pagination in a business app would be rarely useful for a business app that is properly (best practices) designed.

What we find is that power users (the ones who have to incorporate large amounts of data in decision-making -- in our instance buyers handling purchases for hundreds of stores on multiple geographic sites) do NOT want to look at large amounts of data; they want to look at an accurate summarization, and then drill down -- into a small amount of data.

So this is a feature with a limited audience, it seems to me. If the feature is limited to those backends that support it, so be it. Supporting SQL2012 makes sense, since the db supports doing so (in response to the need of web apps, btw). What we will tell customers is the simple truth: SQL Server doesn't support pagination in a reasonable manner until SQL2012.

Having queried these same customers, two things are apparent. First, the mobile apps they are requesting are not big data apps: they are useful, limited purpose apps (which we are currently creating in Lianja, hitting their existing data in MS SQL), where pagination is not required. Second, their heavy data hitters do all their work from the desktop, in Corporate HQ, and will continue to do so. And even with that, we have _never_, in the 25 years the company has been in business, had a request to make browses of huge data available. There's no business purpose to it.

Thanks for all the working you are doing in accommodating user's needs. I do think this is one place where a line has to be drawn, and that doing so will not limit the writing of business apps in Lianja.

thanks,

Hank