Hi,
Yes, released in the cache not on the disk, any subsequent read from the disk that happens before the cache writeback will have spurious results.
A properly setup network works, but throw in incorrect DNS/DHCP & TCPIP settings, a bit of viral activity & an Open file agent which is buggy (The old Oplocking problem again) and you have problems.
From my experience, properly setup networks are few and far between.
>>Hi,
>>It usually occurs if read & write caching aren't disabled.
>
>Hi Neil,
>
>Do you really think so?... I would have thought that the problem with enabled read/write cacheing is that the RLOCK() would be released too early, not that it wouldn't be released.
>
>Jim
>
>>
>>>We have a system deployed to about 500 different customer sites. Occasionally (very infrequently given the usage of the system) a program will hang up waiting for the release of a record lock -RLOCK()- set up by a user on another terminal.
>>>
>>>This happens at some clients several times a week and other clients never. It sometimes occurs on a terminal when all other users are at the Main Menu. For these reasons, and through code inspection, I've pretty much ruled out the cause being an RLOCK that is not followed by an UNLOCK.
>>>
>>>In your experiences, can records fail to unlock because of quirky hard drives? Any other ideas would be most welcome.
>>>
>>>Thanks,
>>>
>>>Rudy
Regards N Mc Donald