Record locking

[John Esak]

Bill,
In the case you describe below... this network is working improperly or
improperly configured. This is not a filePro situation or problem.
John


> -----Original Message-----
> From: Bill Akers [mailto:billa at mgmindustries.com]
> Sent: Wednesday, March 31, 2004 1:03 PM
> To: John Esak
> Cc: filePro mailing list
> Subject: Re: Record locking
>
>
> John Esak wrote:
> >>I saw a similar situation years ago running windows ?? over a lantastic
> >>network. I believe that I set PFSYNC to ON or ALL in filepro and did
> >>something to the network also to cause it to write the cache after each
> >>transaction was saved at the workstation. I could never go back and find
> >>what it was because it was so long ago but it definitely had to do with
> >>network and/or windows holding transactions in the cache until forced to
> >>write them to disk.
> >
> >
> >>--
>
> >>_______________________________________________
> >
> > I understand what you are saying... and it probably _does_ have
> to do with
> > Windows somewhere somehow... but filePro is working with
> in-memory values...
> > not those written to disk... so if you say:
> >
> >       num=ctl(1) and then refer to it later... filePro is using
> its own copy
> > in memory of that value... it doesn't matter _when_ it gets written to
> > disk... it is going to be written in the proper sequential order of
> > things... or at least that is the way it is supposed to work... :-)
> >
> > John
> >
>
> 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.  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.  However, usually if a
> workstation had processed two or more transactions, then the information
> would be updated and new information stored, which says to me that a
> write buffer was in use by one or the other of the
> systems(windows/network) and required forcible flushing to make sure
> that each transaction was immediately stored. That was what PFSYNC and
> whatever else we did at the time accomplished.
>
>
> --
> William Akers
> MGM Industries, Inc.
> Hendersonville TN USA