Sergey,

>By default SET TABLEVALIDATE is set to 3. It requires Visual FoxPro to validate table header every time it opens any table. In order to do that Visual FoxPro has to get a header lock. In the case of the second instance it cannot because the first instance has file lock. You can SET TABLEVALIDATE TO 0 before openning the table in question to eliminate the problem. It's up to you how to use SET TABLEVALIDATE TO in the rest of your application.

Thanks, I can understand that, but due to specifics of implementation of my application, the usage of fLock() makes it more suitable (at least that's what I think).

The code below (that I posted in my message) belongs to a program (called "Task Scheduller") that runs in a Win 2K server, it runs continuously (7x24) and fires tasks to perform various functions.

This code is executed in the very beginning of program activation:

 TASK_LockFile = "MyTable.dbf"

 Use (TASK_LockFile)  In 0   Alias TASK_LockFile

 Set Reprocess To 1 Seconds

 If ! fLock ("TASK_LockFile")
    Wait Window TimeOut 20 "TASK_LockFile already locked"
    Quit
 endif

 Set Reprocess To Automatic

 Select  TASK_LockFile
 Go      Top

 Replace LF_LockDat  with  DateTime ()

Another program ("Task Central") of the same system, can be run by some end users, at their PCs, so they can check if their "tasks" are running, finished, to fire tasks manually etc, all those tasks will be fired by the "Task Scheduller" (code above) in the Win 2K server.

In order to know if the "Task Scheduller" is running, the "Task Central" performs the following code upon activation:

 Use  (TASK_TaskTable )  In 0   Alias TASK_TaskTable

and the code below, any time it needs to know if the "Task Scheduller" is still running (to know if it can pass "messages" to the "Task Scheduller" etc):

 If TaskSchedIsRunning ()
    . . .
 endif
 
 . . .
 
 Function TaskSchedIsRunning
*-------- ------------------
 Local bItIsRunning

 Set Reprocess To 1 

 bItIsRunning = ! fLock ("TASK_LockFile")

 Set Reprocess To Automatic

 UnLock In TASK_LockFile

 Return bItIsRunning

 EndFunc

All this was running ok till this morning when I recompiled "Task Central" with VFP 8 (previous version of the executable was compiled with VFP 6).

The point here is: has fLock() changed its behavior since version 6 (in this case docs don't reflect it) or this is a bug?

Thanks for your kind patience!

Fernando