Uniface 10.4 and Informix: Simple Guide to Transaction Control 💾

Why transactions matter 💡 ## Transaction logging in Informix 🧱 ## Never commit inside SQL strings 🚫 ## Multiple connections vs. global transactions 🔀 ## Two-phase commit support ✅ ## Simple practical tips 🧰 This article gives a simple overview of how transaction control works when you use Uniface 10.4 with an Informix database. 😊 This post was created with the help of an AI assistant and is based on the official Uniface 10.4 documentation about “Transaction Control on Informix”. Transactions help you keep your data consistent. Either all changes are saved, or none of them are saved, which is very important in financial, medical, or other critical systems. All these actions should be part of one transaction. If something fails, you want to roll back everything. Informix can work with or without transaction logging. So, if you want real transaction control, make sure that logging is turned on for your Informix database. Uniface lets you send SQL directly using the sql ProcScript statement. However, you must not put commit or rollback into the SQL string when you use the single connection mechanism. Example of what not to do: Better: keep your business SQL and your transaction control separate: In this version, Uniface manages the transaction on the logon path correctly. Uniface and Informix also support a multiple connection mechanism. In this mode, you can have several open connections, and each connection has its own transaction. But you cannot have one atomic transaction that covers both FINANCE and LOGGING at the same time just by using normal Informix transactions; for real distributed transactions you need a transaction manager and XA support. Informix supports Two-Phase Commit (2PC) for XA-compliant environments, and this is handled largely transparently by the database and the transaction manager. The important point: you do not need special commit SQL statements inside your Uniface SQL strings to “enable” 2PC; the infrastructure around Informix handles that. Here are some simple rules you can follow in daily work: With these rules, your Uniface 10.4 applications can use Informix transactions in a safe and predictable way. 🚀 Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK: ; ❌ bad practice in single connection sql "update orders set status = 'PAID' where order_id = 123" sql "commit" Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: ; ❌ bad practice in single connection sql "update orders set status = 'PAID' where order_id = 123" sql "commit" CODE_BLOCK: ; ❌ bad practice in single connection sql "update orders set status = 'PAID' where order_id = 123" sql "commit" CODE_BLOCK: ; ✅ better: let Uniface control the transaction sql "update orders set status = 'PAID' where order_id = 123" if ($status >= 0) commit ; Uniface commit else rollback ; Uniface rollback endif Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: ; ✅ better: let Uniface control the transaction sql "update orders set status = 'PAID' where order_id = 123" if ($status >= 0) commit ; Uniface commit else rollback ; Uniface rollback endif CODE_BLOCK: ; ✅ better: let Uniface control the transaction sql "update orders set status = 'PAID' where order_id = 123" if ($status >= 0) commit ; Uniface commit else rollback ; Uniface rollback endif - You insert an order into an ORDERS table. - You insert order lines into an ORDER_LINES table. - You update the customer’s credit balance. - If there is no transaction logging, the database does not manage transactions in a way that supports safe commit and rollback operations; changes are effectively written without the option of a full transactional rollback. - If transaction logging is enabled, Informix supports both commit and rollback, so Uniface can use transactions safely. - In the single connection mechanism, a logon path can be shared by multiple logical paths. - If you end a transaction on that logon path, you end the transaction for all paths that use the same connector. - Multiple concurrent transactions are supported: each connection can start, commit, and roll back its own transaction. - Global transactions, where a single transaction spans several databases over multiple connections, are not supported by Informix as a native feature in this Uniface connector context. - Connection A uses database FINANCE. - Connection B uses database LOGGING. - Start a transaction on A, do some updates, and commit A. - Start a transaction on B, do other updates, and roll back B. - Two-Phase Commit is a protocol used to make sure that a distributed transaction either commits everywhere or rolls back everywhere. - In a setup with a transaction manager, Informix takes part in this process, while Uniface still uses its usual commit and rollback ProcScript statements to signal transaction boundaries. - Make sure transaction logging is enabled if you need safe commit and rollback. - Do not put commit or rollback inside SQL strings when using the single connection mechanism; use Uniface’s commit and rollback instead. - When using multiple connections, remember that each connection has its own transaction, and Informix does not provide one global transaction across several databases in this setup. - If your environment uses Two-Phase Commit, let Informix and the transaction manager do the heavy lifting; keep your Uniface code clean and simple.