My concern with live-lock is the possibility that
two transactions are interlocked. Transaction 1
updates record A and tries to update record B.
Transaction 2 updates record B and tries to update
record A.

In a "wait" transaction the server notices that
the two transactions are waiting for each other
and produces a "deadlock" error - not just an
"update conflict".

If both transactions are "no wait", then they
are, in fact, never waiting for each other.
The server has no way to recognize the problem,
so they continue until they system reboots.

My recommendation? Use a wait transaction, commit
or rollback when you see an "update conflict" error
and retry your operation, including re-reading the
records you based the change on. I realize that
the IBX (BDE?) version of "data driven" controls
makes that very awkward. My reaction to that is
use a better tool, but that's getting political.

What works is to issue a dummy update while you're
gathering data. The update can be to a specific
record, or to a generic "gateway" record. Until
that update succeeds, don't start reading data.
When it does, your update will protect your access
to the record (or set of records if you're using
a gateway.)

Regards,

Ann