|Re: [IBO] Strange behaviour
> - It's better to change the UI with simple to understand and intuitiveI just have an OK and Cancel for the user, and sort out the
> buttons instead of using the bars
> - Do you suggest that I always start/close the transaction by myselfDon't need to 'start' if you are just going to save a single
> (explicit transaction) instead of letting IBO do it by itself?
bit. I just 'CommitRetaining' as part of an 'OK'.
I use 'start' when I have to add line items to an order, so
that I can Cancel the whole order if required, but it does
mean problems with multiple records being locked while the
parts for an order are updated. I may need to change to
commit at each stage - securing stock for each line item -
and then if the order is cancelled unroll back myself - but
it has not come to that yet <g>
> - Is it better, in general, to use Autocommit or is it better toI use both, but the OK button needs Commit(Retaining), while
> explicitly commit/rollback in code when needed?
backgound logging is done with Autocommit. As usual no hard
and fast rules.
> - In general, how many transactions do I have to use to operate onIn the main I just have a single Transaction per Connection,
> each table? One unique transaction to open/close the query and to
> perform all DML tasks on that table (as I'm doing now) or two, one to
> open/close the query and another for DML tasks? Is it safe to use one
> for all?
and in most cases a single connection - but I don't use DML
at present. One for all works fine.
> Well, apart the tech info taken from Jason's site and the InterbaseThe tech stuff is the best available at present - but it is
> manual, is there any other good (simple to understand :-) reading
> about transactions somewhere?
improving all the time with help from users.
L.S.Caine Electronic Services