How come transactions aren't happening the way I want them to?
The interaction of the Query Widgets and the Data Source widgets is unavoidably complex. This example program is designed to help you learn the ins and outs of controlling transaction behavior with DX. DX supports various kinds of Update and Commit behavior. Running the example program here will allow you to test different behaviors. The Query and Data Source widgets are wired here to show you just what is happening for each combination of settings.
Building and Running the Transaction Trainer
Copy the source code and the .uil file to a convenient directory; load the .uil file and regenerate the C++ code. This will create a makefile for your site and installation. Compile the C++ code and run the Transaction Trainer.
.In the upper left part of the screen, a static message is present which tells whether your database even supports Transactions. Most databases created with Informix, Oracle, and Sybase are configured to support Transactions and Rollbacks. Auto transactions can be turned off and on. You may observe that commits are done straightaway with auto transactions turned off.
The remaining radio buttons set the values of the three remaining resources which control transaction behavior.
"At Edit" updates the database when the mouse moves to a new column.
"At Motion" does so when it moves to a new row.
"Never" means that automatic updates never occur. (Presumably you would write code of your own to do so.)
From working with the Transaction Trainer, you can see that the application's Query and Data Source widgets both contribute to the overall commit behavior. You can experiment with the 9-element matrix to explore various combinations.
The three basic choices are:
Commit as soon as the Query Widget updates,
Commit when the mouse goes to a new row, and
Never commit (by itself that is). Presumably again, you would write your own code to issue the commit command.
ICS Support Crew, March 1997
Download the transaction trainer source
