To determine if the call really is auto-committing, try creating a second Oracle procedure containing a rollback and calling that via a proxy procedure right after the call t_proxy_to_oracle( 'qwerty123' );

FWIW a SQL Anywhere 12 remote database does not exhibit this behavior; i.e., the rollback is done on the remote database.

AFAIK Oracle does not auto-commit itself, it's a client thing, which in this case might be the ODBC driver.

With invoke ROLLBACK by calling oracle proxy procedure - same result:

-- oracle alter sql:
create procedure t_remote_rollback
is
begin
    rollback;
end;

-- asa alter sql:
create procedure t_proxy_to_oracle_rollback( ) at 'etbos;;bos;t_remote_rollback'

-- asa test sql:
delete from t_proxy_call_param;
commit;

begin tran;
    call t_proxy_to_oracle( 'qwerty123' );
    call t_proxy_to_oracle_rollback( );
rollback;

select * from t_proxy_call_param; /* 1 row selected */

Another test SQL:

call t_proxy_to_oracle( 'qwerty123' );
commit;
select * from t_proxy_call_param; /* 1 row selected */

begin tran;
    delete from t_proxy_call_param;
    select * from t_proxy_call_param; /* 0 row selected */
rollback;
select * from t_proxy_call_param; /* >> 1 row selected << */

Thus, delete through the same ODBC driver supports distributed transaction

Because the decision and is not found, suggest that we go on the other hand: someone is opportunity to check for similar configuration?

If the error only on my configuration will somehow find that leads to commiting. And if such working with proxy tables-SQL Server established Anywhere (for example, described in the documentation), then the solution will be completely different.

Sorry, my English is not very good.