jdvries@cs.vu.nl (Vries de Jeroen) (06/19/91)
I need some help with what seems a bug in Foxpro/LAN. When I want to add records to a file on more workstations simultaneously I run into the following problem. If one of the workstations allready has one ore more records locked (which is allways so in my case) it does not detect the fact that another workstation might have appended a record before it does. Result is that both workstations think they have a new record whereas there is only one new record created. When neither of the workstations have any locks on the database, the problem soe not occur. I think I tried allmost every permutation of the different MULTILOCKS,DELETED etc... settings but the bug persists resulting in a multi-user system that can only append new data from one workstation at a time. Is this a known problem and better yet, is there a cure (other than abbandoning FoxPro?) Thanx... -- ---------------------------------------------------------------------- J. de Vries, jdvries@cs.vu.nl | Piece is relative. <The BitSplitter.> Tel:02907-4732 | ----------------------------------------------------------------------
dhartung@chinet.chi.il.us (Dan Hartung) (06/20/91)
jdvries@cs.vu.nl (Vries de Jeroen) writes: >I need some help with what seems a bug in Foxpro/LAN. >When I want to add records to a file on more workstations >simultaneously I run into the following problem. If one >of the workstations allready has one ore more records >locked (which is allways so in my case) it does not detect >the fact that another workstation might have appended a >record before it does. Result is that both workstations >think they have a new record whereas there is only one >new record created. When neither of the workstations have >any locks on the database, the problem soe not occur. >I think I tried allmost every permutation of the different >MULTILOCKS,DELETED etc... settings but the bug persists >resulting in a multi-user system that can only append new >data from one workstation at a time. This is not a bug with FoxPro, it is a problem common to xBase languages. There is a great literature on how to work around problems like this. I suggest you go straight to your bookstore and buy "Developing FoxPro Applications" by P.L. Olympia and Kathy Cea. It has some 45 page just on multi-user techniques. One method that might work for you is to implement your own record locking, with a LOCKED logical field in the record and an explicity LOCK(). One easy and often effective method is to SET REPROCESS TO <high number>. I don't know if it would affect your problem, tho. >Is this a known problem and better yet, is there a cure >(other than abbandoning FoxPro?) FoxPro 2 is supposed to be a little more intelligent about this. -- Daniel A. Hartung | "What's the difference anyway, between being dhartung@chinet.chi.il.us | safe and being rad, the joke's on us, we've Birch Grove Software | all been had." -- John Wesley Harding -----------FoxPro Programmer Looking For Work--------------
cy@dbase.a-t.com (Cy Shuster) (06/21/91)
In article <10261@star.cs.vu.nl> jdvries@cs.vu.nl (Vries de Jeroen) writes: >I need some help with what seems a bug in Foxpro/LAN. >When I want to add records to a file on more workstations >simultaneously I run into the following problem. If one >of the workstations allready has one ore more records >locked (which is allways so in my case) it does not detect >the fact that another workstation might have appended a >record before it does. Result is that both workstations >think they have a new record whereas there is only one >new record created. When neither of the workstations have >any locks on the database, the problem soe not occur. >I think I tried allmost every permutation of the different >MULTILOCKS,DELETED etc... settings but the bug persists >resulting in a multi-user system that can only append new >data from one workstation at a time. > >Is this a known problem and better yet, is there a cure >(other than abbandoning FoxPro?) I don't know for sure about FoxPro, but dBASE IV has an internal APPEND lock, explicitly to prevent two people from APPENDing at the same time (disk full problems, etc.). The answer is to pre-allocate records which can be replaced by anyone, along with a record which holds the next available value. If you know what the new keys will be, this will also speed up performance, as otherwise an APPEND BLANK followed by a REPLACE causes two updates to the relevant indices, while if you preallocate new records with the key in place (perhaps as deleted records?), you take no hits on the index, only the data portion. Anyone have any better techniques? (There are several ways to serialize new integers across a network that are more efficient than causing everyone to bottleneck on a data record with the next available number. Use the Baskin-Robbins model, for example.) --Cy-- cy@dbase.a-t.com