Edit Extended / Edit WorkArea - ABM / ABM2
Moderator: Rathinagiri
Re: recordlocking
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
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
- esgici
- Posts: 4543
- Joined: Wed Jul 30, 2008 9:17 pm
- DBs Used: DBF
- Location: iskenderun / Turkiye
- Contact:
Re: recordlocking
Dear Richardt57042 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.
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
Re: recordlocking
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
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
- esgici
- Posts: 4543
- Joined: Wed Jul 30, 2008 9:17 pm
- DBs Used: DBF
- Location: iskenderun / Turkiye
- Contact:
Re: recordlocking
Hi Richard
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 :
For any further problem(s) please inform us.
EDIT EXTENDED successfully implemented for network conditions.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.
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. )
Viva INTERNATIONAL HMG
Re: recordlocking
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
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
- esgici
- Posts: 4543
- Joined: Wed Jul 30, 2008 9:17 pm
- DBs Used: DBF
- Location: iskenderun / Turkiye
- Contact:
Re: recordlocking
If in the both stations is running your same program under same OS, must be no problem.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.
Please check this and inform us about result.
Regards
Viva INTERNATIONAL HMG
Re: recordlocking
Same program - 1 Os = Windows XP other is W7.
This program works OK on same configuration :
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
-
- Posts: 1
- Joined: Sun Nov 11, 2012 5:29 pm
Re: Where is the code for the EDIT WORKAREA CLIENTES?
found the h_edit.prg but it's all in spanish.
does anyone have an english version ??
does anyone have an english version ??
- esgici
- Posts: 4543
- Joined: Wed Jul 30, 2008 9:17 pm
- DBs Used: DBF
- Location: iskenderun / Turkiye
- Contact:
Re: recordlocking
Hi Richard
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
Duration of record locking process is ( and must ) very short time; locks, write to disk, and unlock.t57042 wrote:But when editing a record I can open that same record on the 2d station without getting a "record locked" message.
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
Re: recordlocking
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
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