Hi Jorge,
Which version and build of SQL Anywhere / dbremote is this? Do you have a console log file from dbremote illustrating this issue?
In this case there was a legitimate database error that should not affect that particular remote database but since multiple db operations are grouped in one commit then the roll back is rolling back the db operations for different logical unit of works making the other legitimate transaction that do not have a db error.
Rollback transactions and rollback operations within committed transactions should not be replicated amongst remotes - if you are seeing this, it is possible you are encountering a bug. Do you by chance have the execution conditions listed in this bug description here?
http://search.sybase.com/kbx/changerequests?bug_id=738756
If so, this condition is fixed in SQL Anywhere builds 11.0.1.2982, 12.0.1.3899, 16.0.0.1538.
Is there any way to force dbremote to do the commits the same way that it was originally done when the database transaction was originally posted
You could set "dbremote -g 1" to guarantee this, but I don't have any confidence that this would be a solution for you based on your problem description.
Regards,
Jeff Albion
SAP Active Global Support