> If you use a stored procedure for a database task which
> you know results in no change to the work package then
> set the IBDSQL.IB_Transaction property to IB_TRANSACTION(nil)
> so the IB_TransactionBar will not accumulate the database
> action.

Generally you should keep everything that needs to act on the same
data context on the same transaction (since a stored procedure
executing on a different transaction would not see uncommitted changes
from the primary form transaction).

Simply set StoredProcHasDML := false which will prevent the execution
from changing the transaction state.

> 1. Is the correct way to specify a default transaction to
> make it IB_Transaction(nil)?

You also need to be sure that TIB_Session.AllowDefaultTransaction is
true. Drop TIB_SessionProps onto the mainform to give you designtime
access to these properties.

> 2. When a transaction MyTr is programatically started by
> MyTr.StartTransaction an associated IBTransactionBar has
> buttons CommitRetaining, RollbackRetaining (and others)
> enabled. I am thinking these buttons say "You have done
> work which is available to be committed or rollbacked."
> and would prefer the buttons not be enabled at
> StartTransaction. Perhaps there is another way to look
> at this.

In Interbase a physical transaction must be started even just to read
data (it defines the data context - what versions of records are
visible to all statements within the transaction).

Because a transaction has been started it will need to be closed
(preferably before too long). If you have explicitly called
StartTransaction then you will disable IBOs automatic handling of the
physical transaction and must be sure to commit/rollback the
transaction to close it yourself. If you let IBO start the
transaction only when required then it will (in certain circumstances)
attempt to close the physical transaction automatically - while still
keeping your form in an appropriate state by maintaining a "logical"
transaction. There is more on this in the online help and the
tutorial apps.

IBO takes the relatively conservative with the dataset and transaction
states and I do think this is appropriate. Unlike saving a normal
document to disk, simply posting a record to the database can have
side effects, even if no changes were made to the values (the triggers
will fire anyway). So it is not really upto IBO to stop you from
posting when no data is changed, it may be intentional.

The additional checks that you make in your application to prevent
redundant posts is really up to you.

> 3. It wold be desireable to have the IB_ComboBox not trigger
> a dssEdit state whe the current value is reselected. However,
> one can avoid using the IB_Combobox altogether by making a
> table with its items and using a IBLookupcombo component.
> But this adds complexity.

I am inclined to agree - I must check my own Enh combobox and see what
it does in this situation.

Be aware that you can also turn AutoEdit off at the datasource. I do
this in my application so that the user must explicitly put the form
in "edit mode" to enable changes to any fields.


Geoff Worboys
Telesis Computing