In SQL-92 compliant relational databases, views that are defined using a SELECT query have certain restrictions. Which clause is not allowed inside the defining SELECT of a view (i.e., the view's query text itself)?

Introduction / Context:
SQL views are virtual tables defined by a stored SELECT statement. Standards such as SQL-92 impose rules on what the defining query may contain. Understanding these rules helps avoid portability problems and subtle errors when designing database abstractions.

Given Data / Assumptions:

• The question targets SQL-92 behavior for view definitions.
• We are considering clauses that appear inside the SELECT used to create the view.
• The goal is to identify which clause is disallowed in the view’s defining query.

Concept / Approach:
Views represent unordered sets of rows. Because a view may be referenced from other queries that apply their own ORDER BY, the standard forbids embedding ORDER BY in the view definition. Other clauses like FROM, WHERE, GROUP BY, and HAVING are allowed because they define filtering and aggregation but do not impose a permanent presentation order.

Step-by-Step Solution:

Verification / Alternative check:
Vendors often note that ORDER BY in a view is ignored or rejected unless combined with vendor-specific extensions (for example, TOP in some systems). The portable, standards-compliant approach is to sort only in the outer query that consumes the view.

Why Other Options Are Wrong:
FROM: Required to specify source tables/views.
WHERE: Allowed for filtering rows.
GROUP BY / HAVING: Allowed to define aggregated views.

Common Pitfalls:
Expecting a view to always return rows in a given order. Without ORDER BY in the outer query, result ordering is never guaranteed.

Final Answer:
ORDER BY