Hi All,

When adding record I sometimes get error 108 "file in use by another user"

I am using the INSERT INTO command ...

I added a SET REPROCESS TO 10, but the problem occurs anyway, randomly.

Does anyone have any experience with this, especially with the SET REPROCESS parameters ?

SET TABLEVALIDATE TO 0 ?

Hi Vincent

set tablevalidate acts only when USEing the table.

set reprocess retries to access a locked record or table, see the help for all options.

Thanks Thierry, but:

*"The table (.dbf) header is locked during validation. This operation can result in decreased scalability when tables open as shared, for example, when issuing the USE command with the SHARED keyword or calling the SQL SELECT, UPDATE, INSERT, or DELETE commands against a closed table, and SET EXCLUSIVE is set to OFF." *

I prefer a <1 mS delay upon opening a table when the alternative is having table corruption without knowing it.

Just my 0.01 cent.

Running your Web application you're essentially running a network application locally. Multiple apps accessing the same data.

So you will end up with possible contention between tables and all those rules apply. You should look closely at queries to ensure you don't end up with table or header locks which are required to get for INSERT or APPEND BLANK to work.

Personally, I usually SET REPROCESS TO 2 SECONDS in my apps to give enough time for locks to let go and allows access, and with that - even in very busy apps - it's relatively rare to run into locking issues. It can result in slow requests that have to wait, but at least requests can continue and not fail completely.

The key is to make sure that you minimize table or header locks or if you do incur them keep them short. Using Rushmore whenever possible will help, and doing update/insert operations one at time instead of huge bulks helps in this regard.

+++ Rick ---

Thank you all !

I will change my settings and stay alert to any possible lockout situations

Hi Vincent

Additional thinkings…

1. If you manually lock your tables using [R]Lock … unlock, make sure that your lock will be released in any situation, eg. in a single event transaction and/or within a try…catch…finally construct.
   You better rely only on VFP's automatic data locking feature (for details, see Locking Data in help).
2. If you only rely on automatic data locking and you know how long takes your longest data access (eg. select… for a report), you can use this duration in set reprocess to xxx seconds
3. If you don't really know this duration AND you're sure no lock can ever hang around, you can just use set reprocess to automatic
4. of course you must be aware that, like any data-related command, set reprocess scopes to the datasession, the form is you use private datasessions in your forms.

Thank you Thierry, this kind of reflection is always useful !