Record locking

[Kenneth Brody]

Bill Akers wrote:
[...]
> As I insinuated earlier, there were three potential users working
> simultaneously and all of them could have had the same number since the
> network/windows was holding the changes in cache rather than immediately
> writing back to the files on the station that was acting as server as
> soon as one station had asked for a new number.

Then the cache was broken.

> There was enough lag
> that even after a ticket was written and printed and stored, you could
> not always find it in the system from another workstation until the
> filepro session was terminated, in which case the information was always
> updated and the new information was stored.

Then the cache was "very broken"[tm].

[...]

I don't know how much of this applies to filePro, but...

http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html

    Improperly configured Windows networks can lead to data corruption in
    any file system database, including DataFlex. Two Windows networking
    behaviors, opportunistic locking (on Windows servers) and read caching
    (on Windows clients) are the source of the corruption potential. This
    paper discusses these behaviors, their effects and what can be done to
    minimize the chances of data corruption on Windows networks when running
    Visual DataFlex (VDF) and/or DataFlex applications.
    [...]

-- 

+---------+----------------------------------+-----------------------------+
| Kenneth |     kenbrody at spamcop.net      | "The opinions expressed     |
|    J.   |    http://www.hvcomputer.com     |  herein are not necessarily |
|  Brody  |      http://www.fptech.com       |  those of fP Technologies." |
+---------+----------------------------------+-----------------------------+