Subject Re: lockrow() From Charlie <tm@tc.com> Date Sat, 14 Mar 2020 16:42:38 -0400 Newsgroups dbase.getting-started Hi Akshat.... Thanks for the info.  That will help a lot! I've actually worked with mariadb and workbench.  I like working with them also especially with php.  But this is just a little enhancement.  I've thought about converting over to that side, but oh my gosh the work involved would be enormous!! Akshat Kapoor Wrote: > On 13.03.2020 04:04, Charlie wrote: > > I'm just exploring this for my network.  Is that what lockrow() does?  Protect a row from others using it until it is saved?  I was looking in the duflp for a .cc file that might do something like this but couldn't find one.   Any other info on this?  I'm hoping to fix a problem with my network that would give a message when a row is in use when someone tries to change it.  Not sure how messy this will get but shows promise to fix my problem. > > > > Thanks for any comments. > > > > Good morning Charlie, > This is in addition to what Ken and Wilson have already said. > > If you are using datalinked entry fields then the row is automatically > locked. > > If someone else tries to edit that row then a error message pops up > saying that unable to get a lock. > > The lock is released when save() abandon() or navigate methods are executed. > > Now coming to my favorite excuse : What happens if a user begins edit > and moves out of the office for some time. No one will be able to edit > the row. > > Now coming to my main query. > 1. How many users will be using the tables simultaneously. > 2. What would be the frequency of edits (rare quiet often etc.) > 3. What is the database you are using .dbf tables or some other backend > database. > 4. Are you planning to move to network or you are building a new app. > > I started with using .dbf tables and had high rate of edit from remote > computers as well. > I faced issues over network. > > I have shifted over to backend database MariaDB and I am more than happy > with the shift. > > Working with backend database requires a completely different approach > than working with .dbf tables. > > So if you are building a new app I will strongly recommend a backend > database (Firebird, MariaDb, MySql) are just some of the choices. > > If you are upgrading then you will have to decide if you want to shift > or not. > > Change is easy at this stage and may be difficult later on. > > Regards > Akshat