views:

1010

answers:

3

Hello,

In Entity Framework, using LINQ to Entities, database paging is usually done in following manner:

int totalRecords = EntityContext.Context.UserSet.Count;
var list     = EntityContext.Context.UserSet
           .Skip(startingRecordNumber)
           .Take(pageSize)
           .ToList();

This results in TWO database calls.

Please tell, how to reduce it to ONE database call.

Thank You.

+2  A: 

Hmmm... the actual call that uses paging is the second one - that's a single call.

The second call is to determine the total number of rows - that's quite a different operation, and I am not aware of any way you could combine those two distinct operations into a single database call with the Entity Framework.

Question is: do you really need the total number of rows? What for? Is that worth a second database call or not?

Another option you would have is to use the EntityObjectSource (in ASP.NET) and then bind this to e.g. a GridView, and enable AllowPaging and AllowSorting etc. on the GridView, and let the ASP.NET runtime handle all the nitty-gritty work of retrieving the appropriate data page and displaying it.

Marc

marc_s
You need the total records so you know how many pages you have in your paged interface. I wonder if you could just do a list.Count or something?
rball
Well, the List.Count probably would fetch all rows from the database - that's definitely not something you want. Also, I am pretty sure Linq to Entities will return an empty set of you ask for a page beyond it's actual set of data - so again: why do you need the total number of rows? Really? Sure it's nice to show "Page 5 of 17" on your page - can you live without it?
marc_s
Thanks for replies.UI requires a pager bar, so total record count is needed.
dev
If you do paging on a static data, the totalRecords will the same and shouldn't be retrieved on every page change. If data may change between pages, this may confuse a user.
Kamarey
Thanks.The objective is to reflect current rows (including new additions and deletions).
dev
@marc_s: Are you serious: *"Do you really need the total number of rows? What for?"* Have you ever read anything about interface usability? I must say it's very rare to see an interface that doesn't display last page number but just `Next`. Interestingly enough Google search results don't really display the actual number of pages but just an indicator that gets adjusted on the last page. But still. This is not so much about displaying **`« Previous` Page 5 of 17 `Next »`** but more about `1` `2` `3` `4` `5` ... `17`.
Robert Koritnik
@Robert: I see that a lot - but the question remains - is that **really** necessary? Are you willing to pay the price for enumerating over a huge data set just to know how many rows there are in total? Just a question - maybe you do need that - but then you need to be willing to pay the price for that feature - it's always a tradeoff in computing.....
marc_s
+1  A: 

Using Esql and mapping a stored procedure to an entity can solve the problem. SP will return totalRows as output parameter and current page as resultset.

CREATE PROCEDURE getPagedList(
@PageNumber int,
@PageSize int,
@totalRecordCount int OUTPUT
AS

//Return paged records

Please advise.

Thank You.

dev
+1  A: 

Whats wrong with two calls? They are small and quick queries. Databases are designed to support lots of small queries.

A developing a complex solution to do one query for paging isn't going give you much pay off.

Casey Burns