Another for Lan Network

[Silvio.Falconi]

I 'm trying to run a small test into Lan Network

Now it seem run, I can open and save customer.dbf



I made

USE &(oApp():cDbfPath+cDbf+".dbf") ;
INDEX &(oApp():cDbfPath+cDbf+".cdx") ;
ALIAS &(cAlias) NEW SHARE

and I change giving to oApp():cDbfPath all the exact directory

::cExePath := cFilePath(GetModuleFileName(GetInstance())) //+ "\"

oApp:cYearPath := "2018"

oApp:cDbfPath := ::cExePath+oApp:cYearPath+"\dbf"+"\"

But I'm not convinced yet,

the program never stops even when it has to delete a record that another computer is editing,

I have deleted the number 1 from the customer.dbf file but this record was in edit mode on another computer

how is this possible?

obviously in the save record I used

Code: Select all  Expand view  RUN

If !Occupated("CU")
             Replace CU->Id       with nId
             Replace CU->First    with cFirst
             Replace CU->Last     with cLast
             Replace CU->street   with cstreet
             Replace CU->City     with cCity
             Replace CU->State    with cState
             Replace CU->Zip      with nZip
             Replace CU->Hiredate with dHiredate
             Replace CU->Married  with lMarried
             Replace CU->Age      with nAge
             Replace CU->Salary   with nSalary
             CU->(DbCommit())
             CU->(Dbunlock())
          Endif

the function Occupated(cAlias) with Rlock

Code: Select all  Expand view  RUN

FUNCTION Occupated(cAlias)
   LOCAL lRet:=.F., Sigue:=5
   DEFAULT cAlias:=Alias()
   DO WHILE Sigue>0
      IF (cAlias)->(RLock())
         Sigue:=0
      ELSE
         INKEY(0.5)
         Sigue:=Sigue-0.5
         IF Sigue<=0 .AND.;
            MsgYesNo("!Registration occupied by another user!"+CRLF+ ;
                     " Please wait... ",     "Conferma...")
            Sigue:=3
         ELSE
            lRet:=.T.
         ENDIF
      ENDIF
   ENDDO
RETURN (lRet)

I'm not convinced that this can work

[James Bott]

There are two methods of file locking, optimistic and pessimistic.

With optimistic, the user loads and edits the file, then when they are done, the record is locked, saved, and unlocked.

With pessimistic, the record is locked, the user edits it, then it is saved and unlocked.

I have always used optimistic locking and have had few problems. Pessimistic can cause problems with users walking away from their computer while it is in edit mode. Nobody else can edit the record until they save it.

The experience that you had is unusual but can be handled. If the record was legitimately deleted, the save should fail gracefully saying the record has been deleted. It would seem to be a rare case when one user is updating a record that another user feels should be deleted. If there was good reason for deleting it, then there is no loss if the edited data doesn't get saved. You could provide the option for the user trying to save the updates, to undelete the record and then save.

There is really no right or wrong way. If something like this does happen the best you can do is guess the best solution and record what happened so it can be later undone.

It's not a perfect world...

James

If the world were perfect, it wouldn't be.--Yogi Berra

[Silvio.Falconi]

James,
for this topic I not use tdata but only new share

[Otto]

Hello Silvio
If you want the behavior you descript you must lock the record when the user starts editing the record.
You lock immediately before saving the changes. So another user can delete the record in the mean time.
Then you can be sure that no one can change or delete this record.
Best regards
Otto

[James Bott]

Silvio,

I can't think of a good reason to ever delete a customer. Perhaps move them to an "archive" database after a certain period of inactivity, but I wouldn't delete them.

If you allowed a customer to be deleted then you would also have to delete all related records such as orders, invoices, etc. You can see that this could be a nightmare. What about unpaid bills, unprocessed orders, etc. You would have to do all kinds of checks before even allowing a delete. Much better would be to move the customer and everything related to archive databases. Then they can be recovered.