TOPIC:

FoxProMatt wrote: Why can't I delete a record in a cursor? In FoxPro, DELETE command works once a DBF is opened, whether it was opened as Shared or Exclusive.
Getting run-time error "Lock required (Record has to be locked)"

Function TestDelete()
	
	Close Databases
	Set Exclusive Off
	Var lcDbfName =  "C:\Work\lm5\AppData\xSharp_Test_Parent.dbf"

	Use (lcDbfName) Alias WA1 Shared In 0
	Set Deleted On
	IF RLock()
		Delete Next 1
	ELSE
		? "Record lock error"
	ENDIF
	Field cFilename 
	
	Scan For !Deleted()
		? Recno()
		? cFilename 
	Endscan
	
	Wait

End Function

FoxProMatt wrote: In FoxPro, if we have SET EXCLUSIVE OFF, yes it means that any other user can open the DBF, but even so, any user who has it open can still delete one or more records, and that deletion will appear in all other work areas for all users who have that DBF open.

Example: If a DBF is opened as Shared in work area on User 1's computer, and User 2 also opens same DBF in Shared mode, then lets say User 1 deletes a record in the DBF, well then that record will become deleted on User 2's work area also.

Apparently FoxPro monitors the disk file for changes or something because I just tested what I explained to you above and it does indeed work the way I described.

EXCLUSIVE OFF means anyone can open and anyone can add, delete, modify.

EXCLUSIVE ON means no one else can open

What if you delete a record while somebody else is editing the same record and hit the save button after you have deleted?

FoxProMatt wrote:

What if you delete a record while somebody else is editing the same record and hit the save button after you have deleted?

I don't know the details of all the potential race conditions that can pop up.

I know there is a RLock() function and probably other stuff too. My apps don't run against actual DBF files since I use cursors of records from Sql Server. I usually don't even dabble in this kind of code, but I was just testing some basic FoxPro DBF commands and coding and this one stumped me as to why it wouldn't work.

We'll see what Master Robert says about this.

robert wrote: According to the VFP documentation (the chapter "Locking Data") locking is done automatically.

FUNCTION NetTry(bAction AS CODEBLOCK, nRetry := 1 AS WORD, cError := '' AS STRING, lConfirmOverRide := FALSE AS LOGIC) AS LOGIC
	LOCAL lRetry := TRUE, lSuccess := FALSE AS LOGIC
	LOCAL nTried, nTimer AS WORD
	nRetry := Max(nRetry, 1)
	WHILE lRetry .and. !lSuccess
		nTried := Min(5, nRetry)
		WHILE ! ( lSuccess := Eval(bAction) ) .and. ( nTried > 0 )
			nTimer := SetTimer( NULL_PTR, 01, 01, NULL_PTR )
			nTried--
		ENDDO
		KillTimer(NULL_PTR, nTimer)
		IF !lSuccess
			IF lConfirmOverRide
				lRetry := FALSE
			ELSE
				lRetry := (YesNoBox{oSetupVars:Owner, ProcName(), ;
									'*** ' + cError + ' error ***' + CRLF + 'Retry?'}:Show() ==  BOXREPLYYES)
			ENDIF
		ENDIF
	ENDDO
	RETURN lSuccess

IF RLock() .OR. NetTry({|| RLock()}, 5, "Record lock error")

robert wrote: According to the VFP documentation (the chapter "Locking Data") locking is done automatically.

I tried a simple example in FoxPro and monitored its file access with procmon and indeed:
FoxPro silently automatically locks the record when you use the DELETE command for a file that is opened in shared mode.
It does the same for REPLACE statements.
Of course this can cause concurrency problems when 2 users are trying to access the same record.
I tried it by updating the same record from 2 processes on the same machine and guess what: the second process simply overwrites the changes from the first process with no warning at all..
And when one process is editing a value (for example in a grid) and the second process tries to edit the same record then that process keeps on trying to lock that record. I am not sure if it tries to lock that forever, but it certainly did try that for a very long time. Most likely this can be configured somewhere. I saw a reference to "SET REPROCESS".
I tried that with "SET REPROCESS TO 10" and then indeed after several retries when editing a table I see the error message "Record is in use by another user".
So I guess that a correct implementation of the REPLACE, DELETE and RECALL commands in FoxPro should not only update the data but also include automatic locks and unlocks with error handling when locking fails.

FoxProMatt wrote: [You will also have to eventually deal with the CURSORSETPROP() function which allows for row or table buffering to be in place in an app.

lumberjack wrote: It was always at our conferences emphasized how to manage multi-user systems and the one that was repeated over and over again, generic RLock()/UnLock functions/methods.

mainhatten wrote: If your App needs it, you can always RLock() before editing, which carries its own pitfalls. But I think MS range of option for handling update conflict is good enough for optimistic locking to prevail over pessimistic (which they offer in buffering as well).
Best practices might have been explained in more detail

lumberjack wrote: I have done all my programming in a wrapper class Insert/Update/Delete in a Scatter/Gather method and they all basically called the NetTry function that I have shared a couple of days before, nothing fancy but it is solid and I have not touched them since the late '90s. Work even for standalone systems as well as multi-user client server. Less than 100 lines of code.

mainhatten wrote: Certainly not rocket science, but you will run into edge cases where the pessimistic locked records are locked during a telephone call expected to be over in 2 minutes but took 52... I think MS nailed a good default if you have trustable ts_update or better i8_recwrite counter fields which can guarantee optimized access on bulk operations.

lumberjack wrote: Well it is a coding style, you can sit a year on a record in my applications and it won't matter. Very similar approach to MS on my DBFs, not that I use DBF anymore though.

lumberjack wrote: not that I use DBF anymore though.

FFF wrote:

lumberjack wrote: not that I use DBF anymore though.

Would love to see a "VO-StandardMDI"-Sample, backed by a PG-backend in the Gallery .