DBeaver Transaction Mode and Implicit DDL Commits

Direct answer

DBeaver does not expose a built‑in flag that tells you whether a DDL statement caused an implicit commit. When the database engine issues an implicit commit (common in MySQL, Oracle, SQL Server, etc.), DBeaver’s transaction‑status indicator may still show “Manual commit” even though the underlying session has already been committed.

Likely explanation

DBeaver’s Auto‑commit toggle only controls whether it sends a BEGIN; it does not intercept or override the database’s own DDL‑implicit‑commit behavior. Therefore the application cannot know that the server committed unless it queries the server’s session state.

Confirmed facts

1. The Auto‑commit setting is located in the connection properties (right‑click the connection → Edit Connection → Properties). When unchecked, DBeaver precedes each statement with a BEGIN.
2. In MySQL, Oracle, SQL Server and many other engines, DDL statements (CREATE, ALTER, DROP) trigger an implicit commit before and after the statement, ending any user transaction.
3. DBeaver’s UI transaction indicator reflects the last Auto‑commit mode it set, not the actual commit state of the DB session.

Steps needed for this case

1. Verify the Auto‑commit setting in DBeaver for the connection.
2. Run a test sequence to see if an implicit commit occurred:

   START TRANSACTION;
   INSERT INTO test_tmp VALUES (1);
   CREATE TABLE test_ddl (id INT);
   ROLLBACK;
   SELECT * FROM test_tmp;
   SELECT COUNT(*) FROM information_schema.tables WHERE table_name = 'TEST_DDL';
   

   If the INSERT is rolled back (no row) but the table test_ddl exists, the DDL caused an implicit commit.
3. Optionally, check the database session variable (e.g., MySQL: SHOW SESSION VARIABLES LIKE 'autocommit';) after the DDL to see if it changed.

Missing diagnostic detail

To give a definitive recommendation about whether you can avoid the implicit commit, we need to know the specific database product you are using (MySQL, Oracle, PostgreSQL, SQL Server, etc.), because some engines (e.g., PostgreSQL) support transactional DDL and will not commit implicitly.