Hi,

> Doug Chamberlin wrote:
> > Actually a much better way is
> > Start trans
> > Read record
> > Commit
> > Let user edit record taking all the time they want.
> > When they save:
> > Start trans
> > Write updates
> > Commit
>
> But you'll have to worry about whether you are updating the same database
> (as you read from) - you have to control every record that can be affected
> by the inserts/updates/deletes. Not impossible, but a chore.
> I use the timer approach (with commit or rollback), but this isn't without
> problems. I've found users returning from lunch and seeing their work has
> been rejected (rollback) having assumed that whatever they were editing
> (either in a grid or a separate form) has automagically been completed for
> them! Result: the record was never entered into the database.

We once created a system that updated only the modified column in this way:

update mytable set changecol1 = newvalue1, changecol2 = newvalue2
where idcolumn = idvalue and changecol1 = oldvalue1 and changecol2 =
oldvalue2

If the update returned '0 rows affected' we would know there was a 'lock'
error.

Worked great.

Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com

Upscene Productions
http://www.upscene.com

"This is an object-oriented system.
If we change anything, the users object."