Multi user Modification Conflict

Hi
I don't think my users are any more stupid than the average (although a lot of them are juniors with minimal work experience) but virtually all of them find the modification conflict window a challenge and don't really have a clue whether they should accept the changes or not.
With that in mind I am curious as to what others are doing. What we are doing now is writing a class through which all data access is performed. Within that class, we have 2 aliases of our file, one which holds the record as at now and the other which is updated with any changes from our application. When we save a record we read and lock the file, compare on a field by field basis our 'work' alias and our 'original' alias and only update the file with fields that have been changed, thus preserving any changes made by other users to any other fields in the file. I realise that if multiple users were to change the same field/s the last one to save would take precedence but that appears to me preferable to users having to make a judgment call.
Does this seem reasonable, have I missed anything or is there a much simpler way of solving the issue?

Thanks

David

Hello David

Have you considered modifying the Windev window to make it's intent clearer.
C:\WinDev 11\Programs\Data\Preset Windows\Hyper File - Automatic Help Windows\Modif.wdw

It happens very rarely in our apps so we get away with a modified version of the modif window.

Regards
Al

Hi Al
Yeah we tried that and it certainly helped but didn't solve the problem. In our main app that works fine as it is fairly rare for multiple users to be working on the same data, however in this other app it is much more common which is why I was trying to get a decent solution to the problem. Perhaps I need to have another look at our table structure and and see if I can split the main offender into several smaller tables to reduce the occurrences.

David

Hi David,

I really should publish my way of modifying windows after having done the RAD ... Avoiding any conflicts in Form_ and Table_ type windows is no miracle at all !

Before doing HAdd(..) or HModify(..) you have to check whether there is a conflict on any of the unique keys in the file or not! After that you will - depending on the outcome of that check - either save the record or issue a warning, not save anything and eventually move the focus to the control with the control containing the conflict-data.

All code has to put into the local procedure RADSave ! I put the range checks and validation of all of the controls there in order to be sure that only clean and complete data will be saved to the file.

The key check is done by a) saving the file pointer's position b) reading the file using the unique key c) restoring the file pointer to its original position.

Kind regards,
Guenter

EXAMPLE: (most of it is German, however, you should be able to find your way. If not, I can answer your questions ..)

PROCEDURE RADSave()
// Called when clicking the 'OK' button
// Returns 'True' if the record is validated, 'False' otherwise

// Val checks
IF iFaktPerNum < 1 OR iFaktPerNum > 999 THEN
	Error("Die FakturenPerioden-Nummer muß im Bereich 1 - 999 liegen !")
	ReturnToCapture(iFaktPerNum)
END
IF NoSpace(sFaktPerBez) = "" THEN
	Error("Die FaktuerenPeriden-Bezeichnung muß ausgefüllt werden !")
	ReturnToCapture(sFaktPerBez)
END
IF iFaktPerTage < 0 OR iFaktPerTage > 9999 THEN
	Error("Die FakturenPerioden-Tage müssen im Bereich 0 - 9999 liegen !")
	ReturnToCapture(iFaktPerTage)
END

IF Left(gWindowMode,8) = "Creation" THEN
	Ergebnisint = HSavePosition(FAKTPER)
	HReadSeek(FAKTPER,iFaktPerNum,iFaktPerNum,hIdentical)
	IF HFound(FAKTPER) AND iFaktPerNum = FAKTPER.iFaktPerNum THEN
		Error("NEU-ANLAGE: Die FakturenPerioden "+FAKTPER.sFaktPerNumBez+" wurde schon angelegt !")
		IF Ergebnisint > 1 THEN HRestorePosition(Ergebnisint)
		ReturnToCapture(iFaktPerNum)
	ELSE
		IF Ergebnisint > 1 THEN HRestorePosition(Ergebnisint)
	END
END

IF (Left(gWindowMode,5) = "Modif" OR Left(gWindowMode,6) = "Browse" OR Left(gWindowMode,12)="LinkedBrowse") AND iFaktPerNum <> OLD_iFaktPerNum THEN
	Ergebnisint = HSavePosition(FAKTPER)
	HReadSeek(FAKTPER,iFaktPerNum,iFaktPerNum,hIdentical)
	IF HFound(FAKTPER) AND iFaktPerNum = FAKTPER.iFaktPerNum THEN
		Error("ÄNDERUNG: Die FakturenPeriode "+FAKTPER.sFaktPerNumBez+" wurde schon angelegt !")
		IF Ergebnisint > -1 THEN HRestorePosition(Ergebnisint)
		iFaktPerNum = OLD_iFaktPerNum
		ReturnToCapture(iFaktPerNum)
	ELSE
		IF Ergebnisint > 1 THEN HRestorePosition(Ergebnisint)
	END
END




// Transfer controls to file buffer
ScreenToFile()

// The record is valid
RESULT True
	

Thanks Guenter
It's not duplicate records etc that are causing the problem because we already do the validations in a similar manner to yourself. Where we have the problem is 2 users modifying the same record, for example one operator gets a change of phone number to enter whilst another has the change of address (don't ask, its just the way the data comes in unfortunately!). If the timing is wrong, when the operator with the address change tries to save her work she gets the message that the phone number has been modified and that's what we're trying to avoid. Because the operator performing the address change hasn't touched the phone number the record should be saved with the phone number as modified by the other user but without any user intervention. At this point the only way I can see to do that is to re-read the record, update only the fields which have been specifically changed and then save it. Unfortunately ScreenToFile() updates all fields, whether the operator has modified them or not so we have to provide our own routine to do this.

David

Hi David,

The simple way is to manually lock(write) the record during modifcation. Other users cannot access it until it is released. This imposes some inconvenience, but at least it is clear to the user.

Best regards,
Piet