Thanks everyone - this sure looks like the culprit. When/if I can convince the client that they need to make this change, I'll post the result!

Wayne




>>Did you ever resolve this issue? I'm having a similar problem.
>>
>>Thanks,
>>
>>Wayne
>>
>>
>>
>>>I just started working with a new client and ran across something that I can't figure out. Here's the scenario: I'm running VFP 6.0 SP3 (the developer's version, not a compiled vfp app) on a Windows 98 machine connected to a network served by WINNT 4.0 I issue the following set of commands from the command window:
>>>
>>>USE sometable EXCLUSIVE
>>>SELECT sometable
>>>INDEX ON somefield TAG sometag
>>>
>>>USE IN sometable
>>>
>>>* then, for good measure, after experiencing the problem a few times ...
>>>
>>>CLOSE ALL
>>>QUIT
>
>
>This sounds like the Optimistic lock issue - it requires a registry hack at the server end to disable optimistic locking; under Win2K Server, the hack is:
>
>HKLM\System\CCS\Services\Mrxsmb\Parameters
>OpLocksDisabled
>DWORD:0x1
>
>HKLM\System\CCS\Services\LanmanWorkstation\Parameters
>UtilizeNTCaching
>DWORD:0x0
>
>The values likely differ for NT Server; try www.ntfaq.com for similar fixes
>
>>>
>>>At this point, you'd think that the WINNT 4.0 server would see that this table is no longer opened exclusively, right?
>>>
>>>Unfortunately, when users attempt to access that same table through their VFP-compiled app (which, by the way was compiled on the same machine where I'm opening the table), they get a File Access Denied message. And when you look at the open files list on the server, it says that I still have the table open.
>>>
>>>Not until I log out of the network does WINNT indicate that the .dbf is available for shared access.
>>>
>>>Can anyone shed some light on what might be happening here?
>>>
>>>TIA for your assistance.
>>>
>>>DJM