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.
-- TRW
_______________________________________
t i m . w i t o r t
_______________________________________
|
