Commented by: @hvlad

Run your script twice using the same value for DeadlockTimeout ...

Commented by: @hvlad

Add SET AUTODDL OFF at beginning of script and see what happens.

Commented by: @pavel-zotov

No matter whether DeadlockTimeout is odd or even, I get:
1) OK when running script at 1, 3, 5 - i.e. _odd_ times;
2) exceptions 40001 (read conflicts with concurrent update) and 42000 (invalid request BLR at offset 104 // -generator G is not defined) at 2,4,6 - i.e. __even_ times.

C:\MIX\firebird\QA\fbt-repo\tmp>isql /:e30 -i c5080.sql

RDB$GENERATOR_NAME G
RDB$GENERATOR_ID 12
RDB$SYSTEM_FLAG 0
RDB$DESCRIPTION <null>
RDB$SECURITY_CLASS SQL$414
RDB$OWNER_NAME SYSDBA
RDB$INITIAL_VALUE 0
RDB$GENERATOR_INCREMENT 1
GEN_CURRENT_VALUE 0

ISQL Version: WI-V3.0.0.32281 Firebird 3.0 Release Candidate 2
Server version:
Firebird/Windows/Intel/i386 (access method), version "WI-V3.0.0.32281 Firebird 3.0 Release Candidate 2"
Firebird/Windows/Intel/i386 (remote server), version "WI-V3.0.0.32281 Firebird 3.0 Release Candidate 2/tcp (csprog)/P13"
Firebird/Windows/Intel/i386 (remote interface), version "WI-V3.0.0.32281 Firebird 3.0 Release Candidate 2/tcp (csprog)/P13"
on disk structure version 12.0

C:\MIX\firebird\QA\fbt-repo\tmp>isql /:e30 -i c5080.sql
Statement failed, SQLSTATE = 40001
unsuccessful metadata update
-CREATE SEQUENCE G failed
-deadlock
-read conflicts with concurrent update
-concurrent transaction number is 13
After line 9 in file c5080.sql
Statement failed, SQLSTATE = 42000
invalid request BLR at offset 104
-generator G is not defined
After line 30 in file c5080.sql
ISQL Version: WI-V3.0.0.32281 Firebird 3.0 Release Candidate 2
Server version:
Firebird/Windows/Intel/i386 (access method), version "WI-V3.0.0.32281 Firebird 3.0 Release Candidate 2"
Firebird/Windows/Intel/i386 (remote server), version "WI-V3.0.0.32281 Firebird 3.0 Release Candidate 2/tcp (csprog)/P13"
Firebird/Windows/Intel/i386 (remote interface), version "WI-V3.0.0.32281 Firebird 3.0 Release Candidate 2/tcp (csprog)/P13"
on disk structure version 12.0

Commented by: @hvlad

Observed behaviour:
a) have no relation with DeadlockTimeout setting
b) have no mystic and absolutely normal if not forget how ISQL works in AUTODDL ON mode (two transactions, etc)

Commented by: @pavel-zotov

> Add SET AUTODDL OFF at beginning of script and see what happens.

No exceptions after adding this. This is the 1st time I can recall that adding set autoddl OFF can help to solving something rlated to DDL :-)

Commented by: @pavel-zotov

Vlad, can you please explain me:
1) how sequence 'G' could be 'invisible' __after__ commit that is marked here as "[[[[ THIS ]]]]' ?
2) why did I receive opposite results for odd/even values of DeadlockTimeout when script had not 'set autoddl off' statements (see starting post) ?

create sequence g
^
-- commit -------------------------- [ 2 ]
^

create or alter procedure sp_get_remote_data returns(received_value int) as
begin
for
execute statement ('execute block returns(curr_gen int) as begin curr_gen = gen_id(g,1); suspend; end')
on external rdb$get_context('SYSTEM','DB_NAME')
as user 'SYSDBA' password 'masterkey' role 'R_' || right( uuid_to_char(gen_uuid()),12 )
into received_value
do
suspend;
end
^
commit -------------- [[[[ THIS ]]]]
^

Commented by: @hvlad

In AUTODLL ON mode (which is default mode) ISQL handle DML and DDL statements in different transactions.
EXECUTE BLOCK is DML statement therefore ISQL run it in "DML" transaction and doesn't commit it automatically.
CREATE SEQUENCE is DLL and ISQL runs it in different ("DDL") transaction and commits it.
So, you drop generator in "DML" transaction, doesn't commit it and create same generator in "DDL" transaction.
Of course this is classical update conflict scenario.
After isql run COMMIT statement, "DML" transaction is committed and generator is finally dropped.

All this you may see yourself using trace :)