Subject Re: lockrow()
From Charlie <>
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