Member Junction
    Preparing search index...

    Handles server-side pagination for query SQL by applying platform-specific paging clauses.

    The statement is read from tokens (AnalyzePagingShape), so paging works the same way on SQL the AST parser cannot read, and the query's own text is kept as written: nothing is re-emitted from a syntax tree.

    The query's own row cap is part of what it means. StartRow and MaxRows page within the capped result, so the smaller of the query's cap and MaxRows wins, and the total row count is the size of the capped result. A numeric cap (TOP n, LIMIT n [OFFSET k], OFFSET k … FETCH NEXT n) is replaced by the page's own clause with the arithmetic folded in; a page past the cap is an empty result. Any other cap (TOP … PERCENT, WITH TIES, an expression) is kept, and the query is paged as a derived table.

    Data SQL — appends OFFSET/FETCH (SQL Server) or LIMIT/OFFSET (PostgreSQL) to the statement, after its ORDER BY (a default one is added when it has none) and before any clause that must stay last (OPTION (…), FOR UPDATE). Column scopes, ORDER BY references and table aliases stay valid because the query is not wrapped.

    Count SQL — puts the query (without its ORDER BY, unless its own cap needs it) in a [__count] CTE beside the query's own CTEs and selects COUNT(*) AS TotalRowCount.

    A query that ends in FOR JSON / FOR XML returns a document, not rows, and cannot be paged; asking to page one is an error.

    Index

    Constructors

    Methods

    • Extracts the top-level ORDER BY clause from SQL, ignoring ORDER BY inside subqueries, block comments, line comments, single-quoted strings, and bracket/double-quoted identifiers.

      Preserves the public static API for existing callers and tests.

      Parameters

      Returns { orderByClause: string | null; sqlWithoutOrder: string }

    • The offset to page from: the caller's StartRow, or 0 when they named none.

      Kept beside ShouldPage so the two cannot drift — every site acting on a true ShouldPage needs a concrete offset, and StartRow is not guaranteed to be set.

      Parameters

      • startRow: number | undefined

      Returns number

    • Determines whether the given params indicate paging should be applied.

      A MaxRows on its own is enough — a caller asking only to cap a result, rather than to walk pages, still gets the ceiling applied in SQL. Without that, such a call falls through to the provider's full-fetch-then-slice path, where the database returns every row and the whole set crosses the network before being trimmed.

      Matches how RunView decides the same question (BuildTotalRowCountSQL treats rows as limited when usingPagination || maxRowsForQuery > 0).

      An absent StartRow means page zero; see ResolveStartRow. A negative one is rejected.

      Parameters

      • startRow: number | undefined
      • maxRows: number | undefined

      Returns boolean

    • Strips a TOP N or TOP (N) clause from the beginning of a SELECT statement.

      Parameters

      • sql: string

      Returns { sql: string; topRemoved: boolean }

    • Applies a row cap to the outermost SELECT: the result returns at most maxRows rows.

      The statement is edited in place, from tokens, so the caller's SQL is kept exactly as written apart from the cap, and SQL the AST parser cannot read is capped the same way:

      • No cap of its own: TOP n goes after SELECT [ALL | DISTINCT] on SQL Server, and LIMIT n at the end on PostgreSQL. A SQL Server set operation (which has no single SELECT to put TOP on) gets OFFSET 0 ROWS FETCH NEXT n ROWS ONLY after its ORDER BY.
      • A numeric cap of its own: the tighter of the two wins.
      • Any other cap of its own (TOP … PERCENT, WITH TIES, an expression, caps on more than one branch): the statement is capped as a derived table. Clauses that must stay last (OPTION (…), FOR UPDATE) stay last.

      A statement that ends in FOR JSON / FOR XML returns one document built from its rows; it is capped in place (bounding the rows the document is built from) and left unchanged where only a derived table or a set-operation clause could cap it. Anything that is not a single read query (a write, SELECT … INTO) is left unchanged; the render pipeline refuses those before this point anyway.

      Non-positive, non-finite, or fractional maxRows are sanitized (<= 0 and non-finite are no-ops; fractional values are floored).

      Parameters

      Returns string