Hi Tim,

what other things could give this error ?
could it be the buffer count / size and or the "table max read lock count" ?
in that case : what should be the values in a network to have a good
performance ?

Erik


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in bericht
news:624CD47C-D6C8-4D8F-B384-693C1120FAD4@news.elevatesoft.com...
> Erik,
>
> << there is a tape backup and our application does not use de DBIsam
> backup function. I agree that **something** must be problemmaker. >>
>
> You wouldn't get a "read lock error on table xxx" error if the problem is
> being caused by an external software component or the OS.  The read locks
> are completely a DBISAM construct.  If there was an external backup/OS
> issue, you would see an error like "OS error - access denied" or something
> similar.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com

Maybe it's the Windows server opportunistic locking problem.
There is an excellent description at the following link, albeit for a different database:

http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html

Hi Tony,

the locking is set to lpPessimistic in the dbisam session

should I do something in Windows also ?
( it's a Windows SBS 2003 server )

Erik

"Tony Pomfrett" schreef in bericht
news:468EAEC1-6298-4CED-82DA-B86D09B3CCF7@news.elevatesoft.com...
> Maybe it's the Windows server opportunistic locking problem.
> There is an excellent description at the following link, albeit for a
> different database:
>
> http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html
>
>

Erik,

The op lock problem is to do with settings in the server's registry and the client pc registry - nothing to do with DBISAM settings. You could try disabling the op locking on the server and client computers. Instructions can be found at the link in the previous post. Make sure you understand what you are doing before editing the registries.

Tony.

Erik,

<< what other things could give this error ? could it be the buffer count /
size and or the "table max read lock count" ? >>

The only thing that could cause this type of issue is if another DBISAM
session has a write lock on the table in question.  Other read locks will
not cause such a problem, nor will transaction locks when someone has an
active transaction.   However, write locks do not normally last more than a
few milliseconds, so the problem could only occur if the write lock stayed
present longer than it normally would.  If there is an external software
layer interfering with the duration of a file write (Post, Delete), then the
write lock may stick around longer than necessary.

Is there any anti-virus software, or something similar, running on the
server in question ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim, Tony,

thanks for your answers. I  will contact this customer and check those
things.

Regards,

Erik


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in bericht
news:7B76D0B7-3245-408B-BA86-F8095963EF33@news.elevatesoft.com...
> Erik,
>
> << what other things could give this error ? could it be the buffer count
> / size and or the "table max read lock count" ? >>
>
> The only thing that could cause this type of issue is if another DBISAM
> session has a write lock on the table in question.  Other read locks will
> not cause such a problem, nor will transaction locks when someone has an
> active transaction.   However, write locks do not normally last more than
> a few milliseconds, so the problem could only occur if the write lock
> stayed present longer than it normally would.  If there is an external
> software layer interfering with the duration of a file write (Post,
> Delete), then the write lock may stick around longer than necessary.
>
> Is there any anti-virus software, or something similar, running on the
> server in question ?
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com