||Sat, 14 Mar 2020 16:42:38 -0400
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
> 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
> 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.