Did this solution work ?
>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