END

Enterprise command reference.

Command Snapshot

Field	Value
Category	Session and Transaction Control
Mutates Data	Yes/Depends
Scope	Session / Transaction
Privilege Model	Session-scoped variants require session rights; global variants require administrative privilege.

Purpose

Executes the END SQL command with MonkDB distributed runtime semantics.

Syntax

END [ WORK | TRANSACTION ]

Operational Notes

• Use schema-qualified identifiers in automation and automation pipelines.
• Validate behavior in staging for cluster-impacting or governance-impacting changes.
• Confirm runtime effects through system tables and metrics before and after execution.

When to Use

• Use to control session behavior, cursors, or transaction compatibility settings.
• Use when client compatibility or session-scoped runtime behavior must be explicit.

When Not to Use

• Avoid relying on PostgreSQL-compatible clauses whose behavior is intentionally no-op in MonkDB.

Common Errors and Troubleshooting

Symptom	Likely Cause	Action
Permission denied / unauthorized	Missing privilege on object or cluster scope	Re-run with required grants or elevated admin role.
Analysis/parse error	Syntax variant or object shape mismatch	Compare with canonical syntax and object definition.
Runtime failure under load	Resource limits, breaker pressure, or node state transitions	Check sys.jobs, sys.operations, sys.checks, and retry after mitigation.

Cross-References

• SQL Command Catalog
• SQL Commands Index
• SQL Reference Overview

Detailed Reference

MonkDB does not support traditional transactions, as its focus is on scalable read/write performance and analytical capabilities rather than transactional use cases. Here's an expanded explanation of the END command and MonkDB's approach to transactions.

SQL Statement

END [ WORK | TRANSACTION ]

Description

The END statement in SQL is synonymous with COMMIT. In databases that support transactions, it marks the conclusion of a transaction and makes all changes permanent. However, in MonkDB:

• Transactions are not supported; thus, commands like BEGIN, COMMIT, and ROLLBACK are accepted for compatibility but are effectively ignored.
• The primary purpose of the END statement in MonkDB is to close all cursors without hold in the current session.

Why MonkDB Doesn't Support Transactions

MonkDB prioritizes high performance, scalability, and ease of use for analytical workloads. Supporting transactions would significantly impact SQL performance. Instead:

• Every write operation is automatically committed and replicated across the cluster.
• MonkDB uses version numbers for rows to provide consistency. This allows for patterns like optimistic concurrency control (OCC), which can address some use cases requiring atomicity.

Parameters

• WORK | TRANSACTION- Optional keywords. They have no effect.

Alternatives for Transaction-like Behavior in MonkDB

For operations requiring transactional guarantees like transfer X credits from User A to User B, please follow the below:

• Optimistic Concurrency Control (OCC): Use the _version system column to perform version-aware updates:

UPDATE accounts
SET balance = balance - 100
WHERE user_id = 'user_a' AND _version = 4;

If another process updated the row, the _version check fails and no row is updated.

• Single Process Control: Perform complex multi-step logic within one service/process to reduce race conditions.

• Hybrid Approach: Use MonkDB for analytics, logs, time series, and external transactional DB (like PostgreSQL) for things like money transfers.

Examples

Example 1. Basic Example: Committing a Transaction

-- These are executed immediately and independently.
INSERT INTO Customers (CustName, City, State, Country)
VALUES ('John Doe', 'New York', 'NY', 'USA');

UPDATE Orders SET Product = 'Laptop' WHERE Id = 5;

Note: Anything related to TRANSACTION are accepted for compatibility, but MonkDB does not support multi-statement transactions. Each statement runs independently.

Example 2. Conditional Commit or Rollback

INSERT INTO Customers (CustName, City, State, Country)
VALUES ('Jane Smith', 'Los Angeles', 'CA', 'USA');

There’s no rollback, and MonkDB does not allow conditional control flow inside SQL. However, this flow must be in app level. For example,

# pseudo-code or real application logic-- MonkDB + psycopg2 or asyncpg
try:
    rows_affected = cursor.execute("""
        INSERT INTO Customers (CustName, City, State, Country)
        VALUES (%s, %s, %s, %s)
    """, ('Jane Smith', 'Los Angeles', 'CA', 'USA'))

    if rows_affected == 0:
        print("No row inserted. Skipping further actions.")
    else:
        print("Insert successful. Proceeding...")
        # perform next action
except Exception as e:
    print("Error occurred:", e)
    # optional: log, retry, or take compensating action

Example 3. Workaround to SAVEPOINT

Each DELETE, INSERT, or UPDATE is independent and atomic.

DELETE FROM Customers WHERE ID = 1;

-- This runs immediately and cannot be rolled back
DELETE FROM Customers WHERE ID = 2;

If an error occurs, only that individual statement fails — there is no rollback to a previous state.

Nested Transactions Example

-- Insert a new customer
INSERT INTO Customers (CustName, City, State, Country)
VALUES ('Alice Brown', 'Chicago', 'IL', 'USA');

-- Update an order independently
UPDATE Orders SET Product = 'Tablet' WHERE Id = 3;

• Each statement is executed independently.
• There is no transactional context — if the UPDATE fails, the INSERT is not rolled back.
• BEGIN, END TRANSACTION, or named transactions like MainTransaction or SubTransaction are ignored or invalid.

---

See Also

• Begin