RLOCK() and Table Buffering 1

[bobmpalmer]

If I have a buffererd table with say
CURSORSETPROP("Buffering",3,"TABLE") and I issue RLOCK()on a record, is the lock applied to the record in the underlying table making that record un-available for other users or is RLOCK() overridden by the buffering?


Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[bborissov]

Yes, you lock the actual record.

Borislav Borissov
VFP9 SP1, SQL Server 2000/2005.
MVP VFP

 

[Mike Lewis]

Bob,

Also, be aware that if you issue RLOCK() on a row-buffered table, you will do an implicit TABLEUPDATE() (just as you would if you moved the record pointer).

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[bobmpalmer]

Many tks Boris. I wasn't sure and having trolled through MSDN for half a day my brain has become addled.


Mike thats useful aswell I didn't realise that though thinking about it its obvious really.

Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[bobmpalmer]

Mike, Ive just tested this and it does'nt appear to be so My code was originally:-

IF goodlog		
	SELECT LOGPRINT	
		
	APPEND BLANK
	REPLACE logdate WITH DATE(),;
		logtime WITH TIME(),;
		logprog WITH gcHomename ,;
		logperson WITH gcUsername,;
		logterm WITH netname(),;
		loggedon WITH .t.
		=RLOCK()
	IF CURSORGETPROP("buffering","LOGPRINT")>1
		TABLEUPDATE(0.,.T.)
	ENDIF
ENDIF

However, if I comment out the TABLEUPDATE() The loggin lock fails!!

Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[bborissov]

RLOCK() Works on psychical records not on virtual one. Until you TABLEUPDATE() that records didn't exists in the table, nobody else could see it - so you don't need to LOCK it. If you want to LOCK it do that AFTER TableUpdate():

IF goodlog        
    SELECT LOGPRINT    
        
    APPEND BLANK
    REPLACE logdate WITH DATE(),;
        logtime WITH TIME(),;
        logprog WITH gcHomename ,;
        logperson WITH gcUsername,;
        logterm WITH netname(),;
        loggedon WITH .t.
    IF CURSORGETPROP("buffering","LOGPRINT")>1
        TABLEUPDATE(0.,.T.)
    ENDIF
    =RLOCK()
ENDIF

Borislav Borissov
VFP9 SP1, SQL Server 2000/2005.
MVP VFP

 

[bobmpalmer]

Aha, Yes Boris thank you very much. That would explain the spurious results I was getting.



Bob Palmer

http://www.resisystems.co.uk

The most common solution is H2O!

 

[Mike Lewis]

RLOCK() Works on psychical records

Are psychical records the ones used in look-ahead buffering?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[bborissov]

If you lock them who cares

What I meant was that the RLOCK() lock the records that is already in table and saved on disk.

Borislav Borissov
VFP9 SP1, SQL Server 2000/2005.
MVP VFP

 

[USMA99]

Hmm, 'psychical records', your humor was not lost on me Mike...

 

[Imaginecorp]

Hello Borislav;

I have no doubt that your solution works... I am little lost.

We have never locked records since VFP5, all tables are opened in optimistic table buffering in the DE and we use a conflict catcher class...thus the question:

Why would you lock a record, After an Update has been done and the new values saved?

Also you were right about the Dll, could not even get it to register on a machine with no VFP...

Bob: Why not open the table in buffered mode, rather than buffer it before a Tableupdate(), Also would you not need Multilocks on?

Mike: 'psychical' ... {lol} good one