Mike,

>Obviously I know next to nothing about it at the moment but this Take business seems to fly in the face of core SQL principles. Operations are supposed to be set-based, not based on record order. Not to mention making assumptions about how many records correspond to how many display pages.

First, there is a "Skip" operator that goes with "Take" to tell you how many "pages" to skip over. Without the "skip" operator, you get the first n set of records matching the query. This is not based on record order, btw, but on order of records matching a query's where clause, ordered by a certain expression.

This scenario is, however, a very common one for apps to use in web-based apps. You run a query that might return 1500 matching records, but you don't want to display them all in one huge HTML table. So, you grab just the first n records that match. Then you click Next on the web interface and you have to go get the next n records that match the same query.

How would you go about doing that? Pull all the matches to the local machine and then step through those n at a time? Fine if your dev environment can handle it (or if it can just USE table and set filter :-) ), but what about web apps where you can't efficiently store a large set of records for each user to page through.

You have to use a Top n query, usually with a subselect that uses some complex magic to handle skipping over page * n records. In SQL Server 2005, you get a @@RecordNum (I think that's it) to use in the subselect. Oracle has something similar. I've done it in VFP too, but don't remember the syntax off the top of my head (I looked it up in Tamar's SQL book).

I think your problem is with the names they gave (see below) and not the concept after all.

>I do not find Take to be a particularly intuitive clause name, either. Unlike From, Into, Where, etc. its meaning doesn't seem clear.

Well, because each database has its own syntax for writing a query to do paging, LINQ itself should use a database-agnostic term -- thus Take and Skip. Under the covers, those will be translated into the correct SQL statement to send to the backend (LINQ to SQL knows what database you are using and adjusts the SQL it creates accordingly).