Briefly, things fo like that:

1. If the command with the FOR clause is a command that can modify the table (ex. REPLACE), the whole table is locked (not only the current processed record).
2. If the command with the FOR clause is a command that cannot modify the table (ex. COUNT), the whole table is locked only if SET LOCK is ON. If SET LOCK is OFF, no record is locked. Things get more complicate when "clever" tricks are used (like a UDF that modifies the table from the FOR clause).

So, as an answer to your question: yes, there's a direct relation between table lock and FOR clauses and a multiuser application must deal with this. And is almost sure the errors you experience is caused by FOR clauses.

Basically, it's very easy to correct this: just replace the command with FOR clause with SCAN FOR and command without FOR. It's slower but it locks only the current record.

Take a look to SET LOCK in the help file for a list of commands that depend on this setting when they use FOR clause. Also, it's good to know that SET LOCK is
scoped to the data session.

The easiest way to test these things: open two instances of FoxPro, open the same table in both of them, etc. You simulate two users in this way, etc.

HTH,
Vlad

>I need an answer from someone who really knows what's going on "behind the scenes".
>
>We are experiencing network related error messages as more and more users use our app. The error messages are: "Attempting To Lock..." and "Record Not Available, Please Wait..."
>
>I was told that one way to minimize such errors was to avoid FOR clauses whenever possible.
>
>I was told that FoxPro places a lock on a table when using a FOR clause in order to prevent values from changing during the FOR clause operation.
>
>I tried to test to see if this was happening. When I ran the tests, I found no evidence that a table lock was being placed.
>
>I need to know A.S.A.P. if I should rewrite my code. It is affecting our largest clients and they are getting impatient.
>
>Thanks in Advance,
>Shawn Nelson