Duplicate rows after PhpStorm retries a failed INSERT when Auto‑commit is disabled

Answer first

No. PhpStorm does not guarantee an implicit rollback before re-executing a statement after a connection loss when Auto-commit is disabled. The console will retry the last statement as-is on reconnect, and with Auto-commit off the previous attempt may have already succeeded on the server while the client lost the commit acknowledgement. That can produce a duplicate row on retry.

Continue on error does not control the connection-loss retry. It only controls whether the console proceeds to the next statement after a SQL error within a batch execution.

Confirmed facts vs likely explanation

Confirmed facts

• With Auto-commit disabled, PhpStorm keeps a JDBC transaction open until you explicitly Commit or Rollback. The IDE does not auto-commit each statement.
• Continue on error is a batch execution setting. It decides if execution continues after a SQL error in a multi-statement run. It does not enable or suppress the automatic retry-on-connection-loss behavior.
• Data Sources and Drivers allows a reconnect action to be configured per data source: Commit, Rollback, or Do nothing on reconnect.

Likely explanation for duplicates

• Automatic retry on connection loss re-executes the last statement without a guaranteed implicit rollback of the previous attempt.
• If the first INSERT reached the database and was written in the open transaction before the network dropped, the retry will run the same INSERT again in the same or a new transaction. With Auto-commit off and no rollback on reconnect, the first uncommitted change can remain pending and the second INSERT creates a duplicate.
• Whether the first change is kept or discarded also depends on the database and JDBC driver. Some databases roll back uncommitted work on connection drop, others keep it until timeout. Driver behavior can override IDE settings.

Actual behavior is version and driver dependent. No universal implicit rollback before retry is assured across environments.

Steps to prevent duplicate writes in this case

1. Open Data Sources and Drivers, select the data source, and check the reconnect action. Set it to Rollback rather than Commit or Do nothing to reduce risk of reusing an uncommitted transaction after reconnect.
2. For console work with Auto-commit off, avoid relying on automatic retry for non-idempotent writes. Either enable Auto-commit for single-statement ad-hoc inserts, or manually Commit immediately after a successful INSERT before any risky operation.
3. Make writes idempotent where possible: use a unique natural key with a UNIQUE constraint, or use INSERT ... ON CONFLICT / INSERT IGNORE / MERGE semantics supported by your database.
4. Disable automatic retry for the console if you cannot make the statement idempotent. The retry setting is per data source and can be turned off to force manual re-execution.

Verification you can do safely:

• Disable Auto-commit, run a test INSERT into a throwaway table, note row count, simulate a disconnect, observe console retry messages and row count after reconnect.
• Repeat with reconnect action set to Rollback and compare row counts.
• Test Continue on error with a deliberate SQL error to confirm it only affects batch continuation, not connection-loss retry.

One missing diagnostic detail that changes the recommendation: PhpStorm version and database + JDBC driver. The location of reconnect and retry options and the exact reconnect semantics changed across releases, and MySQL, PostgreSQL, Oracle and others handle dropped uncommitted transactions differently.