VB.NET ↔ ADO.NET: Transactional Rollback Scope for DDL Statements in SQL Server

When a Visual Basic .NET application uses SqlTransaction to wrap a schema change such as ALTER TABLE or DROP COLUMN, the goal is to determine whether the DDL can be rolled back if a later data manipulation step fails. The constraint is that SQL Server issues an implicit commit for most DDL commands, so the transaction started in VB.NET code does not encompass the schema change. Provider documentation confirms this behavior for SQL Server, yet the exact boundary where the implicit commit occurs—whether it is at statement execution, at batch completion, or at the first DDL encountered—remains a practical uncertainty for developers writing Try...Catch...Finally blocks in VB.NET.

What is the precise point in the ADO.NET command pipeline where SQL Server performs the implicit commit for DDL? Does wrapping the DDL in a separate SqlCommand but the same SqlTransaction change the outcome? Can a savepoint or nested transaction mitigate the effect, or is the only reliable pattern to separate schema deployment from application transactions entirely?