I think this error occurs exactly because no begin work statement was set.
the users want to commit a transaction that is not there.
Not in transaction.
The database server cannot execute this COMMIT WORK or ROLLBACK WORK statement because no BEGIN WORK was executed to start a transaction. Because no transaction was started, you cannot end one. Any database modifications that were made are now permanent; they cannot be rolled back but do not need to be committed. Review the sequence of SQL statements to see where the transaction should have started.
This error can occur when you open a cursor for update and have not started a transaction yet.
I don't know if you are still struggling with this problem or resolved it already, but which OS are you running on, and do you have any other SDK's in the mix?
We were experiencing odd transaction boundary behavior, using Informix SE 7.25 and Client SDK 2.80 (includes ODBC 3.8) on Red Hat Linux 7.3 (gcc 2.96). The C++ application maintains one or more continuous connections to the DB through a RogueWave SourcePro layer, and it turns out that the database was interpeting the connection as a single transaction! (I am not sure why- this might make sense to somebody, but I still think it's stupid, not that I have an opinion on the subject...) So whenever we hit something that triggered a ROLLBACK, it would take out all the work since the app made the connection.
And when we tried to use "BEGIN WORK/END WORK" statements, we would get "Already in a transaction" error responses.
We ended up forcing explicit COMMIT and ROLLBACK statements, trapping for the existing transaction scenario and giving it a COMMIT before explicitly strating our own new one. Not elegant, but at least it seized control back from the black box middle layers. Needless to say, this behavior of the SDK and/or Rogue Wave tool is not well documented or explained anywhere...