| Subject | Re: [ib-support] minimizing transaction-open time |
|---|---|
| Author | Woody |
| Post date | 2002-05-08T14:37:37Z |
From: "csswa" <csswa@...>
except in special circumstances such as support tables, IMO. All "normal"
editing should be done on a single record form where the query only pulls
one record. It is easy to create procedures which let you move forward and
backward through data or locate specific records. Using these types of
methods let's you design your transactions to be short. Moving between
records then becomes: start transaction, read record, edit (or not), stop
transaction, start transaction, read record, etc., etc.
Keeping people from leaving their workstation in the middle of editing a
record is a little tougher to accomplish short of giving them an electrical
shock every time they do it. <g> You can use timers or messaging, to
control this but it's not as cut and dry as it seems. If they are in the
middle of editing and go to lunch and a timer kicks in, whether you commit
or rollback what they are doing could effect other things so a set of rules
must be decided on ahead of time. It might also matter whether they are
inserting a new record or merely editing a current one.
Woody (TMW)
>Grids, in general, should be for displaying data only, not for editing
> As someone who is building a first true CS database (not counting
> Flashfiler and its TFFTables), what is the best approach for
> minimizing the time that a transaction is left open?
>
> Editing in a dbgrid seems like a bad idea in that a user might edit a
> few records, scroll down, edit a few more, take a phone call, edit
> some more, spend ten minutes finalising his lunch order... and 30
> minutes later finally get around to hitting the COMMIT button.
> Meanwhile some other poor sod is trying to update the same table and
> getting a record lock. Is it a better idea to use grids for display
> only and instead pop up a form for editing a record? What about
> making the transaction 'envelope' smaller at the expense of broad
> rollback by soft-committing when the user finishes with one record
> and moves on to the next, instead of letting the user decide when to
> commit?
>
except in special circumstances such as support tables, IMO. All "normal"
editing should be done on a single record form where the query only pulls
one record. It is easy to create procedures which let you move forward and
backward through data or locate specific records. Using these types of
methods let's you design your transactions to be short. Moving between
records then becomes: start transaction, read record, edit (or not), stop
transaction, start transaction, read record, etc., etc.
Keeping people from leaving their workstation in the middle of editing a
record is a little tougher to accomplish short of giving them an electrical
shock every time they do it. <g> You can use timers or messaging, to
control this but it's not as cut and dry as it seems. If they are in the
middle of editing and go to lunch and a timer kicks in, whether you commit
or rollback what they are doing could effect other things so a set of rules
must be decided on ahead of time. It might also matter whether they are
inserting a new record or merely editing a current one.
Woody (TMW)