I have a multiuser system which works well, but I want to improve it.

At the moment if User A edits record X, then User B tries to edit record X all that
happens is that User B cannot edit the record ... it is locked, but no message appears for
User B.

I am guessing that the lack of a message may be to do with my code ... but in any case I
would like to trap the error message & send a 'nice' message to User B.

What event would I have to trap? ... is it OnEditError?

Adam

Adam,

Rather than immediately bailing out, keep trying until some threshhold of
retries. For example:

iCounter: integer;
....

iCounter := 0;
while not (Table.State in [dsInsert,dsEdit])
do begin
 Inc(iCounter);
 if iCounter > iMax then begin
   ShowMessage('Record not available now');
   Break;
 end else ;
 { Do some backoff algorithm, eg, wait 200 ms. & try again }
 Sleep(200);
end;

Jerry

"adam" <adam@nospamplease.fmfoods.co.uk> wrote in message
news:EFEFD89A-F8EE-4376-9DCF-DCD4D32A1A5C@news.elevatesoft.com...
| I have a multiuser system which works well, but I want to improve it.
|
| At the moment if User A edits record X, then User B tries to edit record X
all that
| happens is that User B cannot edit the record ... it is locked, but no
message appears for
| User B.
|
| I am guessing that the lack of a message may be to do with my code ... but
in any case I
| would like to trap the error message & send a 'nice' message to User B.
|
| What event would I have to trap? ... is it OnEditError?
|
| Adam
|
|

"Jerry Clancy" <jclancy@billtrak.com> wrote in message
news:599A7FD4-9AC6-404E-914D-4B159ABD49BF@news.elevatesoft.com...
> Adam,
>
> Rather than immediately bailing out, keep trying until some threshhold of
> retries. For example:
>
> iCounter: integer;
> ...
>
> iCounter := 0;
> while not (Table.State in [dsInsert,dsEdit])

Why would the tTable be in dsEdit when another user is editing the record?

Anyway, if you use optimistic locking, there is no problem with having the
same record edited by multiple stations, you will get the error when two
stations attempt to make changes. Read on locking protocols

http://www.elevatesoft.com/dbisam4d5_locking_concurrency.htm

Robert

Adam,

<< I am guessing that the lack of a message may be to do with my code ...
but in any case I would like to trap the error message & send a 'nice'
message to User B.

What event would I have to trap? ... is it OnEditError? >>

Yes, both OnEditError and OnDeleteError:

http://www.elevatesoft.com/dbisam4d5_updating_tables_query_results.htm

That's version 4.x, but it's similar enough to give you the general idea.

--
Tim Young
Elevate Software
www.elevatesoft.com

Good point. I did that quickly and actually forgot the edits (we had a
four-hour power failure today). Should have been something like this:

Edit;
while not (Table.State in [dsInsert,dsEdit])
do begin
 Inc(iCounter);
 if iCounter > iMax then begin
   ShowMessage('Record not available now');
   Break;
 end else ;
 { Do some backoff algorithm, eg, wait 200 ms. & try again }
 Sleep(200);
 Edit;
end;

Still not complete (eg, might Exit instead of Break or set success flags).

And, I'd rather control the situation than deal with errors.

Jerry


| Why would the tTable be in dsEdit when another user is editing the record?
|
| Anyway, if you use optimistic locking, there is no problem with having the
| same record edited by multiple stations, you will get the error when two
| stations attempt to make changes. Read on locking protocols
|
| http://www.elevatesoft.com/dbisam4d5_locking_concurrency.htm
|
| Robert
|
|
|

I dont think "your" table would be in dsedit,dsinsert mode, as as far as
your app is concerned the record hasnt been edited.
I dont believe there is a way to determine if the record is being editted by
another instance of the application.

"Jerry Clancy" <jclancy@billtrak.com> wrote in message
news:FD1B2DDF-99B3-47BF-9780-6EE436C2161F@news.elevatesoft.com...
> Good point. I did that quickly and actually forgot the edits (we had a
> four-hour power failure today). Should have been something like this:
>
> Edit;
> while not (Table.State in [dsInsert,dsEdit])
> do begin
>  Inc(iCounter);
>  if iCounter > iMax then begin
>    ShowMessage('Record not available now');
>    Break;
>  end else ;
>  { Do some backoff algorithm, eg, wait 200 ms. & try again }
>  Sleep(200);
>  Edit;
> end;
>
> Still not complete (eg, might Exit instead of Break or set success flags).
>
> And, I'd rather control the situation than deal with errors.
>
> Jerry
>
>
> | Why would the tTable be in dsEdit when another user is editing the
> record?
> |
> | Anyway, if you use optimistic locking, there is no problem with having
> the
> | same record edited by multiple stations, you will get the error when two
> | stations attempt to make changes. Read on locking protocols
> |
> | http://www.elevatesoft.com/dbisam4d5_locking_concurrency.htm
> |
> | Robert
> |
> |
> |
>
>

"Jerry Clancy" <jclancy@billtrak.com> wrote in message
news:FD1B2DDF-99B3-47BF-9780-6EE436C2161F@news.elevatesoft.com...
> Good point. I did that quickly and actually forgot the edits

What you missed is the fact that the tTable in your program will be in
dsEdit state only if you have done a tTable.Edit in your own execute, using
that specific tTable. Even if you have two ttables in your program pointing
to the same disk table, you have no way of accessing the DBISAM locks and
testing dsState in one of them using the other. If another station
(technically, if another tTable or live tQuery) is editing the table, you'll
only know if DBISAM tells you, via an error.

>
> And, I'd rather control the situation than deal with errors.
>

I repeat myself. Read the section on locks

> | http://www.elevatesoft.com/dbisam4d5_locking_concurrency.htm
> |

Old habits die hard. I used an inferior product for some 15 years where we
did record locking and unlocking to prevent conflicts and state checking was
done routinely. The DBISAM piece you referred me to is very well written and
well thought out -- my compliments to Tim and, presumably, Eric. The
semaphores are of particular interest. Question: If the process crashes are
the semaphores unlocked? Are they unlocked on table.Close?

Based upon reading this I'm going to make a few adjustments in our code.
We've been using pessimistic locking but may consider changing it since
there are only limited areas where the user can add and edit records.

Actually, had we not had a four-hour power failure yesterday I would have
read it then.

Thanks.

Jerry

"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in message
news:BB8B7E70-6EFE-438A-920E-608F367E2359@news.elevatesoft.com...
|
| "Jerry Clancy" <jclancy@billtrak.com> wrote in message
| news:FD1B2DDF-99B3-47BF-9780-6EE436C2161F@news.elevatesoft.com...
| > Good point. I did that quickly and actually forgot the edits
|
| What you missed is the fact that the tTable in your program will be in
| dsEdit state only if you have done a tTable.Edit in your own execute,
using
| that specific tTable. Even if you have two ttables in your program
pointing
| to the same disk table, you have no way of accessing the DBISAM locks and
| testing dsState in one of them using the other. If another station
| (technically, if another tTable or live tQuery) is editing the table,
you'll
| only know if DBISAM tells you, via an error.
|
| >
| > And, I'd rather control the situation than deal with errors.
| >
|
| I repeat myself. Read the section on locks
|
| > | http://www.elevatesoft.com/dbisam4d5_locking_concurrency.htm
| > |
|
|