Activating SSP ignores subtransactions?

Author: (sochaz)


just very short description of our problem: Uniface (P213 0715_1), Oracle We need to execute Oracle stored procedure, which performs implicit commit. But we need our original transaction not to be affected by this. It seems quite easy to use subtransactions in Uniface. So I created a brand new service, make newinstance with TRANSACTION property set to TRUE, open new paths etc. All my DB work is just fine, I have more separate connections, can store data in that service and does not affect transactions on my original connection (that is in parent component of my service).

Unfortunately, as soon as I activate my Oracle prcedure, which is defined in the signature editor as "Stored Procedure Component (Default)", it seems to be activated on my original path - even though I activate it in the service, which should have his own connections (own transactions). Since my procedure needs to perform commit, all my locked rows (on original connection) are lost, I can't rollback them anymore.

In ulibrary, I figured out, these procedures are executed on the path $SSP. In my .asn, this path is mapped to my main path $DAT. All operation on path $DAT works just fine, but the procedure does not. Seems like quite a big problem, did I missed something? Or is it just a bug in Uniface? AFAIK, new component with property TRANSACTION=TRUE should have his own transaction (and everything activated from that component).


PS: I have even tried to open $SSP again, just like my other paths, but ended up with error -9 (max. logons reached).
PS2: Hope it's understandable. Not an easy situation, should you need some clarification, let me know.


  1. Hi Zdenek,

    not quite sure if this is a possibility for you:

    Instead of mapping $SSP to $DAT like the others do

    Provide an additional ORACLE logon  and map this to $SSP

    You will not see uncommited data from your $DAT, but you will not mess up these transactions.


    Success, Uli

    Author: ulrich-merkel (
  2. I would expect that the way you describe worked.

    A workaround is to have $SSP = ORA:... so that a new DB logon is used. Then this has it's own transaction, even outside the 'brand new' service.

    Author: sjaak (