VB.NET ADO.NET Transactions and Cross-Database DDL Rollback Consistency

Integration Boundary

VB.NET applications using System.Transactions.TransactionScope or explicit DbTransaction objects rely on ADO.NET's common abstraction layer to coordinate work across SQL Server, PostgreSQL, and Oracle. The abstraction promises a single Rollback() call that undoes all enlisted operations, but the underlying providers diverge sharply when DDL statements such as ALTER TABLE or CREATE INDEX are mixed with DML in the same logical unit of work.

Goal and Constraints

The goal is to design a deployment pipeline that can safely revert both schema changes and data mutations together when any step fails, without maintaining separate rollback scripts per database. The constraint is that SQL Server and PostgreSQL support transactional DDL for most commands, while Oracle issues an implicit COMMIT before and after every DDL statement, making true atomic rollback impossible on that platform. EF Core migrations already exhibit this split behavior, yet no built-in VB.NET mechanism detects or enforces the separation at runtime.

Open Questions

• Is there a provider-agnostic pattern in VB.NET that guarantees "all-or-nothing" semantics for mixed DDL/DML batches across these three databases without resorting to database-specific compensation logic?
• Can TransactionScope be configured to throw or escalate when it detects a provider that will silently commit DDL, rather than proceeding with a false sense of atomicity?
• What runtime checks or static-analysis rules can surface this interoperability gap before a production deployment encounters a partial rollback on Oracle?