---
title: Multi-Statement Scripts
url: https://nexyron.tech/docs/cypher/clauses/statement-forms/multi-statement-scripts
description: A Nexyron Cypher script is one query text containing multiple Cypher statements separated by semicolons. The runtime parses the text once as a script, then executes each statement
---

# Multi-Statement Scripts

## Generic Description

A Nexyron Cypher script is one query text containing multiple Cypher statements separated by semicolons. The runtime parses the text once as a script, then executes each statement from left to right on the same session. The final statement result is returned to the caller.

```cypher
CREATE (u:User {uid: 'u1', name: 'Ada'});
CREATE (o:Order {order_id: 'ord-1', user_uid: 'u1'});
MATCH (u:User {uid: 'u1'}) RETURN u.name AS name
```

## Consumer-Level Explanation

Use a script when a workflow is naturally staged: create data then inspect it, compute a global value then compare normal rows against it, run a narrow lookup then use that result in a second lookup, or perform a few ordered maintenance commands in one submitted query text.

Scripts are not a replacement for normal Cypher pipelines. If one statement with `WITH`, `CALL { ... }`, `UNWIND`, or a procedure call is clearer and cheaper, prefer one statement. A script is useful when the stages are easier to reason about as separate statements or when a write must complete before a later read.

## Conceptual Explanation

Each statement is still a normal Nexyron Cypher statement. Semicolons separate statements; they are not part of a clause. Execution is sequential and the session state is preserved, so writes made by an earlier statement are visible to later statements according to the same transaction and autocommit behavior that applies to the surrounding entrypoint.

Only the last statement's rows are returned as the public `QueryResult`. Intermediate results are discarded unless the immediately following statement imports them with [`FROM PREVIOUS`](https://nexyron.tech/docs/cypher/clauses/statement-forms/from-previous).

## Advanced Example

```cypher
MATCH (u:User)
WHERE u.status = 'active'
RETURN u.uid AS uid, u.segment AS segment;

FROM PREVIOUS AS user_row
MATCH (o:Order {user_uid: user_row.uid})
RETURN
  user_row.segment AS segment,
  count(o) AS orders,
  sum(o.total) AS revenue
ORDER BY revenue DESC
```

This script first narrows the user population, then the second statement joins the previous rows to order nodes and returns the final aggregated result.

Another common pattern is computing one global value once and reusing it in the next statement:

```cypher
MATCH (o:Order)
RETURN avg(o.total) AS global_avg_total;

FROM PREVIOUS AS baseline
MATCH (o:Order)
RETURN
  o.order_id AS order_id,
  o.total AS total,
  o.total - baseline.global_avg_total AS delta_from_global_average
ORDER BY delta_from_global_average DESC
```

That shape is useful when the baseline is easier to audit as its own statement and should not be recomputed in a repeated per-row subquery.

## Real Use Cases

-   Exploratory graph work where an analyst wants to create a small fixture and immediately inspect the resulting shape.
-   Global-baseline analysis where a first statement computes a latest timestamp, maximum value, average, threshold, or compact candidate set and the second statement compares graph rows against it.
-   Staged lookups where a first read produces stable business identifiers and the next read expands from those identifiers.
-   Assistant-generated live workflows where several simple steps are clearer and safer than one dense query.
-   Operational scripts that perform a small ordered set of schema, maintenance, or data statements and only need the final status or verification read.

## Real Limitations And Tradeoffs

-   The caller receives only the final statement result. If earlier rows matter, explicitly pass them to the next statement with `FROM PREVIOUS` or return them from the last statement.
    
-   `FROM PREVIOUS` only sees the immediately previous statement's result, not every earlier result in the script.
    
-   A script with many broad scans can still be slower than one well-shaped Cypher pipeline because each statement has its own bind/optimize/plan/execute cycle. Keep previous results compact and use scripts to avoid repeated work, not to hide repeated all-graph scans.
    
-   Persisted abstraction contracts such as abstraction `source_query`, `relation_query`, and feature queries intentionally remain single-statement contracts because they are stored and executed independently.