Tim Witort wrote:
> nonsense seemed to utter in
> news:327c$466ed249$49e5d46$9125@[EMAIL PROTECTED]
>
>
>>Tim Witort wrote:
>>
>>>nonsense seemed to utter in
>>>news:64c59$466e7d08$49e5d12$947@[EMAIL PROTECTED]
>>>
>>>
>>>
>>>>Does any version of VFP have lockfiling built in for
>>>>multi-user apps?
>>>>
>>>>I am currently trying to run VFP5.0 on a network with
>>>>XP and Vista clients and a linux file server. Each
>>>>client has its own VFP. This is intended to be an
>>>>update from multi-user foxbase running under an
>>>>older version of SCO unix.
>>>>
>>>>I am presently able to create database collisions
>>>>as I am set up with VFP on the client machines and
>>>>the app along with databases on the server. My VFP
>>>>5.0 do***entation doesn't address lockfiles so I am
>>>>assuming they don't exist?
>>>>
>>>>The business owner is totally enamored by the accounting
>>>>software he's running and refuses to change, so I'm
>>>>stuck updating from an interpreter that doesn't do
>>>>21st century dates correctly.
>>>
>>>
>>>It sounds like you may be running an app in a multiuser setting
>>>that was not intended for that. VFP definitely has locking
>>>built in - down to the record level. However, if not implemented
>>>correctly, any conflicts would raise errors or not-so-user-friendly
>>>dialog boxes rather than gracefully taking care of things.
>>>People have been successfully writing and using multiuser VFP apps for
>>>about 20 years.
>>
>>Thanks for your reply. The apps are multiuser (sbt accounting)
>>and have run fine that way for the better part of 2 decades
>>under foxbase and mfoxplus. (I'd love to switch them to
>>something other than sbt but they insist on sticking with
>>what they know and love.)
>>
>>Back to the drawing board on this one. I'm doing something wrong.
>>
>>Where does VFP write the lockfiles? In the directory with the
>>database? In the directory that has the app in it? In a VFP
>>directory?
>>
>>Thanks in advance for any light you can shed on this.
>
>
> In VFP, table and record locking are handled in the table
> itself. There are no "lock files." Certain bits in the
> table are reserved for keeping track of locking. So, the
> locking is managed in the DBF itself.
>
> You said in another post that you were able to have one
> user access a record, then another user access the same
> record. Did they both attempt to change the record? That's
> when conflicts happen. In most multiuser systems, multiple
> users can read the data simultanously with no problem. And
> one person can change a record while multiple others just
> read the record. When two or more people attempt to change
> the same record, that's when (proper) locking comes into
> play. You can lock the record before you start editing it
> to be certain that you will be able to save your changes
> with no conflict. Or you can allow editing of the record
> without a lock, then try to lock it right before you save
> the changes. This can result is conflict if, while user
> 1 was editing his copy of the record, user 2 also changed
> the record and saved his *different* changes. When user
> 1 goes to save his changes, you'll get the ol' "buffered
> data doesn't match disk data, overwrite?" scenario.
Thanks for this reply. You've answered all I needed to know.
|
