Edit Extended / Edit WorkArea - ABM / ABM2

Topic Specific Tutorials and Tips.

Moderator: Rathinagiri

Post Reply
t57042
Posts: 148
Joined: Tue Mar 16, 2010 9:46 am
Location: belgium

Re: recordlocking

Post by t57042 »

Well I am not sure of that. In EDIT EXTENDED for example there is a button 'Modify'.
This button is not defined in the sample program but is imho part of the EDIT EXTENDED routine.
So I think it is not possible to insert recordlocking code, to intercept the code when clicking this button or when double clicking the record.

Best regards
Richard
User avatar
esgici
Posts: 4543
Joined: Wed Jul 30, 2008 9:17 pm
DBs Used: DBF
Location: iskenderun / Turkiye
Contact:

Re: recordlocking

Post by esgici »

t57042 wrote:So I think it is not possible to insert recordlocking code, to intercept the code when clicking this button or when double clicking the record.
Dear Richard

Short time ago we (you and me) was chatted about building a new version of Edit Extended by modifying its core.

And upon your request I was post a sample on Edit Extended for change background color and font.

Record locking don't have any difference to implement; you can add required code into you own Edit Extended core code.

If you will have any problem please inform us.

Regards
Viva INTERNATIONAL HMG :D
t57042
Posts: 148
Joined: Tue Mar 16, 2010 9:46 am
Location: belgium

Re: recordlocking

Post by t57042 »

Dear Esgici,

Thank you again for the code you provided (change background color and font) - it is very useful.
I don't know how to convert the sourcecode to .ch code to include.

I found in the function ABM2EditarGuardar( lNuevo ) in the EditRext.prg a use of RLOCK.
I cannot figure out how and when it is used.

A solution would be that when a dbf is opened SHARED then editing, adding and deleting a record would automatically be preceded by a RLOCK.
Another solution is that a parameter be passed to the EditRext indicating that recordlocking is wanted.

If you make changes, make them to the new EditRext so the color adaptations are not lost.

Best regards

Richard
User avatar
esgici
Posts: 4543
Joined: Wed Jul 30, 2008 9:17 pm
DBs Used: DBF
Location: iskenderun / Turkiye
Contact:

Re: recordlocking

Post by esgici »

Hi Richard
t57042 wrote: A solution would be that when a dbf is opened SHARED then editing, adding and deleting a record would automatically be preceded by a RLOCK.
EDIT EXTENDED successfully implemented for network conditions.

Only you need is to make a little attention when call it: open (USE) your table(s) in SHARED mode.

- Use SET EXCLUSIVE OFF command for glabal setting; or,
- add SHARED keyword to your USE command(s); or
- set fifth parameter ( lShared) of dbUseArea() function to .T. ( default is .F. )

For example, in demo.prg ( of EDIT EXTENDED ) change :

Code: Select all

        dbUseArea( .t., "DBFCDX", "TEST1.DBF", "TEST1" )  // line 110
to 
        dbUseArea( .t., "DBFCDX", "TEST1.DBF", "TEST1", .T. )
and 
       dbUseArea( .t., "DBFNTX", "TEST2.DBF", "TEST2"  )  // line 156
to 
       dbUseArea( .t., "DBFNTX", "TEST2.DBF", "TEST2", .T. )
For any further problem(s) please inform us.
Viva INTERNATIONAL HMG :D
t57042
Posts: 148
Joined: Tue Mar 16, 2010 9:46 am
Location: belgium

Re: recordlocking

Post by t57042 »

When opening the dbf's this way I can open them on 2 stations at the same time.
But when editing a record I can open that same record on the 2d station without getting a "record locked" message.
I tried with the demo program in the samples and with your EdRexdemo.prg - same result.

Richard
User avatar
esgici
Posts: 4543
Joined: Wed Jul 30, 2008 9:17 pm
DBs Used: DBF
Location: iskenderun / Turkiye
Contact:

Re: recordlocking

Post by esgici »

t57042 wrote:When opening the dbf's this way I can open them on 2 stations at the same time.
But when editing a record I can open that same record on the 2d station without getting a "record locked" message.
I tried with the demo program in the samples and with your EdRexdemo.prg - same result.
If in the both stations is running your same program under same OS, must be no problem.

Please check this and inform us about result.

Regards
Viva INTERNATIONAL HMG :D
t57042
Posts: 148
Joined: Tue Mar 16, 2010 9:46 am
Location: belgium

Re: recordlocking

Post by t57042 »

Same program - 1 Os = Windows XP other is W7.
This program works OK on same configuration :

Code: Select all

/*browse1
 * MINIGUI - Harbour Win32 GUI library Demo
 *
 * Copyright 2002 Roberto Lopez <roblez@ciudad.com.ar>
 * http://www.geocities.com/harbour_minigui/
*/

* Value property selects a record by its number (RecNo())
* Value property returns selected record number (recNo())
* Browse control does not change the active work area 
* Browse control does not change the record pointer in any area
* (nor change selection when it changes) when SET BROWSESYNC is OFF (the default)
* You can programatically refresh it using refresh method.
* Variables called <MemVar>.<WorkAreaName>.<FieldName> are created for 
* validation in browse editing window. You can use it in VALID array.
* Using APPEND clause you can add records to table associated with WORKAREA
* clause. The hotkey to add records is Alt+A.
* Append Clause Can't Be Used With Fields Not Belonging To Browse WorkArea
* Using DELETE clause allows to mark selected record for deletion pressing <Del> key
* The leftmost column in a browse control must be left aligned.

#include "minigui.ch"

Function Main
dbf="tsunami"
//dbf="klanten"
index="tsunami"
_w=1000
_h=700	

private aFields:={},aBrFields:={} ,alenFields:={}, i
Use &dbf shared
set index to &index
go top
aFields:=dbStruct() // get structure info to an array
for i=1 to len(aFields) // create array for FIELDS
AADD(aBrFields,aFields[i,1])
AADD(alenFields,aFields[i,3]*12)
next i

	SET CENTURY ON
	SET DELETED ON

SET BROWSESYNC on
   
	DEFINE WINDOW Form_1 ;
		AT 0,0 ;
		WIDTH _w HEIGHT _h ;
		TITLE 'MiniGUI Browse Demo' ;
		MAIN NOMAXIMIZE;
		NOSIZE;
		ON INIT go()  ;
		ON RELEASE CloseTables()
		
		DEFINE STATUSBAR
			STATUSITEM ''
			STATUSITEM '<Enter> / Double Click: Edit' WIDTH 200
			STATUSITEM 'Alt+A: Append' WIDTH 120
			//STATUSITEM '<Del>: Delete Record' WIDTH 120
		END STATUSBAR

		@ 10,10 BROWSE Browse_1	;
			WIDTH _w-30 ;
   			HEIGHT _h-90 	;
            FONT 'VERDANA' SIZE 10;   	
			WORKAREA &dbf ;
			WIDTHS alenFields ;
			HEADERS aBrFields ;
			FIELDS aBrFields;
			ON CHANGE ChangeTest() ;
			DELETE ;
			LOCK ;
			EDIT;
            APPEND
			
	end WINDOW
	CENTER WINDOW Form_1
	Form_1.Browse_1.SetFocus
	ACTIVATE WINDOW Form_1
Return Nil

Procedure CloseTables()
    Use
Return Nil

Procedure ChangeTest()
	Form_1.StatusBar.Item(1) := dbf +".dbf" + '   -   Rec: ' + Alltrim(Str(RecNo())) 
Return 
*************************
Procedure go()    	              
	Form_1.Browse_1.Value := RecNo()	
Return Nil	
oldclipperguy
Posts: 1
Joined: Sun Nov 11, 2012 5:29 pm

Re: Where is the code for the EDIT WORKAREA CLIENTES?

Post by oldclipperguy »

found the h_edit.prg but it's all in spanish.

does anyone have an english version ??
User avatar
esgici
Posts: 4543
Joined: Wed Jul 30, 2008 9:17 pm
DBs Used: DBF
Location: iskenderun / Turkiye
Contact:

Re: recordlocking

Post by esgici »

Hi Richard
t57042 wrote:But when editing a record I can open that same record on the 2d station without getting a "record locked" message.
Duration of record locking process is ( and must ) very short time; locks, write to disk, and unlock.

So it's very normal that lack of the "record locked" message. This message came only "write to disk" process failed.

The importance isn't to get this message, but either record locked or not. If record didn't locked, "write to disk" process will fails. Only in this situation we could think about problem.

I hope that this will help you.

Regards
Viva INTERNATIONAL HMG :D
t57042
Posts: 148
Joined: Tue Mar 16, 2010 9:46 am
Location: belgium

Re: recordlocking

Post by t57042 »

Dear Esgici,

I see what is happening now.
The record is indeed locked just before writing to disk.

This is called ‘postlock’ or ‘optimistic’ locking. In this scenario user2 can update a record which is currently edited by user1. When user1 writes his update to disk, user2’s is lost.
The advantage of this method is that the record is only locked for a very short duration.
The disadvantage is possible lost update (can be overcome by reading back the record just before updating and comparing it with the saved original version - when both are equal write is ok)

The method used by the BROWSE command is ‘prelock’ or ‘pessimistic’ locking.
As soon as one user reads a record to update it that record is locked. It stays locked as long as it has not been written back to disk.
The ‘lost update of the other method is avoided.
A disadvantage is that records could be locked longer.

What I would like is the second method implemented in the EDIT EXTENDED code.
So the lock should be made at the moment the intention of editing (or adding/ deleting) is given.

Thanks

Richard
Post Reply