ALTER TABLE DROP COLUMN in Azure SQL Database: Uncertain Rollback Safety

Goal

Determine the exact transactional boundaries for schema changes in Azure SQL Database, specifically focusing on operations that are auto‑committed and cannot be rolled back, and explore whether any configuration can enforce rollback safety.

Current Constraints

• DDL statements are generally transactional, but some, such as ALTER TABLE DROP COLUMN, are auto‑committed regardless of the surrounding transaction.
• No built‑in flag or setting marks a schema change as rollback‑safe; the engine does not expose a transaction‑level checkpoint for DDL.
• Azure SQL Database offers manual snapshots as a rollback option, but these are not automatically created for each schema change and require additional storage and management.

Unresolved Decision

The documentation does not clearly define which DDL operations are auto‑committed versus fully transactional, leaving developers uncertain about predictable rollback behavior.

Specific Questions

1. Which DDL operations in Azure SQL Database are guaranteed to be auto‑committed, and is there an exhaustive list available in the official documentation?
2. Is there a mechanism—such as a server‑level setting or a query hint—to enforce that certain critical schema changes remain fully transactional?
3. Can an application programmatically detect whether a recent schema change is rollback‑safe within the same session, and if so, what metadata or catalog information would be required?