Ok I think I can confirm this is a bug in Intersystems's query provider for Entity Framework.

The order clause is being generated at the same level as the where containing the %VID. Instead, the ORDER BY should be moved inward to a query lower, along with the TOP ALL which it requires. I have an example of the broken and fixed queries below.

How can I submit this as a bug fix? I can't find a project page or anything, is it internal, or on GitHub?

-- This is the InterSystems query (with identifying values and some excess removed for clarity, but structurally intact):

SELECT TOP (10) *
FROM ( SELECT TOP ALL *
    FROM ( SELECT *
        FROM ( SELECT *
            FROM --Some view or table or sub query 
            AS "Extent1"
            WHERE -- redacted client specific fields
        )  AS "Project1"
    )  AS "Project1"
    WHERE %VID > 1
    ORDER BY "Project1". -- Some Sortable Field 
    DESC
)  AS "top" 

-- This is the correct structure for the query (or something similar, the generator may add extra embedded queries...

SELECT TOP (10) *
FROM ( SELECT *
    FROM ( SELECT TOP ALL *
        FROM ( SELECT *
            FROM --Some view or table or sub query 
            AS "Extent1"
            WHERE -- redacted client specific fields
        )  AS "Project1"
        ORDER BY "Project1". -- Some Sortable Field
    )  AS "Project1"
    WHERE %VID > 1     
    DESC
)  AS "top" 

HI Alexander, thank you, I'm aware of this. I am achieving page number in code (note shown) such as follows:

            var page = int.Parse(Request.Query["page"].FirstOrDefault() ?? "1"); // page from query
            var skip = Math.Max(0, count * (page - 1)); // <-- number of records to skip

This doesn't address the original issue, unfortunately. 

Hi Dmitry,

Thank you for your response. .Net Caché eXTreme was interesting... I've read through that page before. The main downside would be having to either implement software on the same server as Caché installation, or having to implement (and maintain, deploy, etc.) middleware and designing my own protocol for remote use.

I'll have a look at the C++ binding. Do you happen to know if this uses telnet as if it was entered by a human user, or some other protocol? I'm not concerned with performance at this point, really, but I am hesitant to interact with the existing telnet in a way that simulates human input as that's not particularly what it was designed for.

Thanks again for your answer, I'll have a look at the C++ code.

Hi Mike,

Declarative programming is not 'pie in the sky' programming, though I can understand how one might be doubtful as the promises are great without much useful proof often given.

The 'killer app' for this kind of programming is manipulating collections, once you've used declarative programming in this context, it will become clear what the power really is. Luckily, 8 of the top 10 popular languages support this style of programming (https://www.tiobe.com/tiobe-index/). [Edit, changed to 8. Pretty sure C and ASM don't have anything like this.]

I don't want to say this is you, but some people have no room for innovation in their work lives, and will never accept new things. That said, this style of programming is at least 40 years old, and comes from Massachusetts! 

For this to be interesting to production developers, Caché would need syntax support for anonymous functions with compiler support to generate objects (similar to the example) with fields for each free variable to implement the closure. Map, filter and reduce implementations in the build-in libraries would be nice but could also be implemented by the programmer.

Interestingly, I would think this sort of thing would be incredibly useful in Caché because of how prominently arrays are used to represent complex data. Certainly, the first step is to get people interested and asking for it.

This post reminded me of something... To paraphrase Anton van Straaten,  closures are the poor man's object; objects are the poor man's closure. 

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html