> Okay, hence this is down to the definition of "single statement".

True. But the transaction is client-initiated, so the interpretation of the
statement should also consider this.

> This in my POV are three statements. Not one.

True.

> This may be one JDBC statement, but these ARE three SQL statements.

Again, true. But exactly this when executed in auto-commit mode can lead to
problems. That's the only issue I wanted to warn of.

> I believe that there CANNOT be such a statement, since sql is ment to
> execute statements atomically.

Agree.

> The internal savepoints you refered to are exactly there to have that
> all-or-nothing-logic.

True.

> So, if you execute single sql statements, you can only end up having done
> everything OR every partiall modification is rolled back by the engine, so
> you have nothing. Commiting nothing is not a problem, so the auto-commit
> of the JDBC-driver is not a problem.

If a single statement is executed - yes. This "compound" statement issue was
recognised by JDBC developers - we have now batch updates where the behavior
in case of error is implementation defined.

> The lession, I learned from that some time ago: Put any sequence of

changes

> into a stored procedure.
> Executing a stored procedure is atmoic, so no problem....

True. EXECUTE BLOCK is also atomic (I think that is FB 2.0 feature).

Roman