Re: Simple Question(s)
- From: nonsense <nonsense@xxxxxxxxxxxxx>
- Date: Wed, 13 Jun 2007 12:43:34 -0500
Tim Witort wrote:
nonsense seemed to utter in
news:327c$466ed249$49e5d46$9125@xxxxxxxxxxxxx:
Tim Witort wrote:
nonsense seemed to utter in
news:64c59$466e7d08$49e5d12$947@xxxxxxxxxxxxx:
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 documentation 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.
.
- References:
- Simple Question(s)
- From: nonsense
- Re: Simple Question(s)
- From: Tim Witort
- Re: Simple Question(s)
- From: nonsense
- Re: Simple Question(s)
- From: Tim Witort
- Simple Question(s)
- Prev by Date: Re: Simple Question(s)
- Next by Date: Suggestion needed - VFP 7.0
- Previous by thread: Re: Simple Question(s)
- Next by thread: Suggestion needed - VFP 7.0
- Index(es):
Relevant Pages
|
