paul@slhisc.uucp (Paul Tam) (04/22/91)
I'm thinking about recode my single user Clipper application into
a multiuser one. Approximately, there are going to be 8 users using
the application at the same time. Users can insert, view, or update
records. Here come the questions.
1) Are Clipper's file locking and record locking functions are good
and enough to handle the application ?
2) Any important things I should consider in my design phase before
I jump into codeing ?
3) Where can I get information on this multiuser Clipper App.
I'm still using Clipper summer'87, should I consider upgrade it to
Clipper 5.0. Is Clipper 5.0 still having bugs (or at least the
incompatability problem with summer'87 programs).
Please throw me some or any ideas.
Thanks in advance
Paultleylan@pegasus.com (Tom Leylan) (04/24/91)
In article <1991Apr22.142236.5188@slhisc.uucp> paul@slhisc.uucp (Paul Tam) writes: > >I'm thinking about recode my single user Clipper application into >a multiuser one. Approximately, there are going to be 8 users using >the application at the same time. Users can insert, view, or update >records. Here come the questions. > > 1) Are Clipper's file locking and record locking functions are good > and enough to handle the application ? > > 2) Any important things I should consider in my design phase before > I jump into codeing ? > > 3) Where can I get information on this multiuser Clipper App. > >I'm still using Clipper summer'87, should I consider upgrade it to >Clipper 5.0. Is Clipper 5.0 still having bugs (or at least the >incompatability problem with summer'87 programs). > >Paul The file and record locking facilities are adequate in Clipper for most multi-user apps. There is a reported difference between the locking mechanisms in dBASE and Clipper so if you hoped to use both on the same files at the same time you'll have to rethink it. A dBase substitute is available written in Clipper called Pocket Dot (shareware) which is what I use for accessing .DBF files. It uses Clipper's .NTX files also. Clipper doesn't have built in semaphores but they can be faked by the use of files (if you need them) or you can add C code to access anything provided by your network operating system. The basic design considerations are : avoidance of deadlocks when opening files (usually handled by simply opening all files in the same order in all places and timing out after a reasonable number of tries). The other design issue has to do with simultaneous updates from more than one station. Obviously it can't happen exactly at the same time but if station 1 reads, station 2 reads, station 2 writes, station 1 writes the data could be totally screwed. This is usually handled by an explicit record lock by station 1, station 2 can read through the lock but can't write... question then becomes what to do if station 1's operator goes to lunch while the record is locked ? Again usually a time out feature is adequate (there are other ways to handle it though). Any book on network programming considerations (particularly one dealing with C) would be useful. As for 5.0 the original release had bugs but the 5.01 update has been released and as a beta tester I can't find a thing wrong with it. tom leylan (ex-Senior Systems Analyst / Nantucket Corp. ) (don't mean to keep writing that but I'd like people to know that I (know what I'm talking about re: Clipper)