I was curious what strategies others use for working with DBISAMEngineError
8708, "Record has been changed or deleted by another user ..." exceptions in
their applications. Currently I get these exceptions when posting a record
change, which of course is after a user has made changes to it on my edit
screen.

I was considering trying to immediately post back a record when it is first
opened for editing, and if an 8708 happens, informing the user that the
record is open and they have read-only access to the details.

Any other ideas would be appreciated.

Thanks,
Johnnie

Johnnie,

<< I was curious what strategies others use for working with
DBISAMEngineError 8708, "Record has been changed or deleted by another user
...." exceptions in their applications. Currently I get these exceptions when
posting a record change, which of course is after a user has made changes to
it on my edit screen.

I was considering trying to immediately post back a record when it is first
opened for editing, and if an 8708 happens, informing the user that the
record is open and they have read-only access to the details. >>

The preferred method is to save the existing edits to a temporary record in
an in-memory copy of the table, refresh the table, and then re-edit the
table and put the changes back into place (provided that the record is still
valid in the eyes of the application).

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:E056BBC3-20EF-44A6-9FFA-0798B06131AC@news.elevatesoft.com...
> Johnnie,
>
> << I was curious what strategies others use for working with
> DBISAMEngineError 8708, "Record has been changed or deleted by another
> user ..." exceptions in their applications. Currently I get these
> exceptions when posting a record change, which of course is after a user
> has made changes to it on my edit screen.
>
> I was considering trying to immediately post back a record when it is
> first opened for editing, and if an 8708 happens, informing the user that
> the record is open and they have read-only access to the details. >>
>
> The preferred method is to save the existing edits to a temporary record
> in an in-memory copy of the table, refresh the table, and then re-edit the
> table and put the changes back into place (provided that the record is
> still valid in the eyes of the application).

I remember reading this before. Is there an example out there on WWW? I use
a few dozen DB-aware controls on a form for editing and do some manually
coded stuff for each edit.

-Johnnie
Looking forward to v5 - congrads!

Johnnie,

<< I remember reading this before. Is there an example out there on WWW? I
use a few dozen DB-aware controls on a form for editing and do some manually
coded stuff for each edit. >>

BTW, I forgot to ask - are you using optimistic locking ?  That's the only
way that you could get an 8708 error on a Post.

<< Looking forward to v5 - congrads! >>

Thanks.  ElevateDB is much better in the 8708 department.  There's a
session-level setting that determines whether you want to see a warning
error if the current row has changed.  And, ElevateDB maintains a
distinction between a row being changed and a row being deleted.  It always
issues an error if the record that you are trying to edit/delete has been
deleted (and possibly re-used), because it knows when a row has just merely
been changed versus when a row no longer exists.

--
Tim Young
Elevate Software
www.elevatesoft.com