Rlock() wonder.. 
Author Message
 Rlock() wonder..

To all clipperheads

While a record (of a shared used dbf) is already locked can the *same* user Rlock() the *same* record again?
Also is there a way to determine if a record is locked or not? I mean a way other than:  IF rlock() ... e.t.c.

Thanks.
--
Pit V



Fri, 18 May 2001 03:00:00 GMT  
 Rlock() wonder..
If you are using Comix or similar, you can determine if a record is locked
by checking whether

ASCAN(DBRLockList(), RECNO()) > 0

To all clipperheads

is there a way to determine if a record is locked or not? I mean a way other
than:  IF rlock() ... e.t.c.

Thanks.
--
Pit V



Sat, 19 May 2001 03:00:00 GMT  
 Rlock() wonder..

Quote:

>To all clipperheads

>While a record (of a shared used dbf) is already locked can the *same* =
>user Rlock() the *same* record again?
>Also is there a way to determine if a record is locked or not? I mean a =
>way other than:  IF rlock() ... e.t.c.

Pit:

Try the following function. It will return .T. if the record can be
modified, IOW if record is locked, the file is locked or used
exclusive.

[Begin Paste]
/***
*   IsRLock() --> lStatus
*
*   Test the current record to see if its locked and return its status
*/
FUNCTION ISRLOCK()
LOCAL   lRet := NO, e
LOCAL   bErr := ErrorBlock()            // Save Error Block

If !Used()
    RETURN( lRet )
Endif

ErrorBlock( {|e| Break( e ) } )         // New error handler
BEGIN SEQUENCE

    FieldPut( 1, FieldGet( 1 ) )        // Try to rewrite same data
    lRet := SI                          // Success

RECOVER USING e

    If e:genCode != EG_UNLOCKED                 // Not a Good Error
        BEGIN SEQUENCE
            Eval( bErr, e )                     // Handle it normally
        END SEQUENCE
    Endif

END SEQUENCE

ErrorBlock( bErr )              // Restore Default Handler

RETURN( lRet )

[End Paste]

Regards,
Amilcar A. Camargo
Sand, S. A.
Guatemala, C. A.



Sat, 19 May 2001 03:00:00 GMT  
 Rlock() wonder..

Quote:

>To all clipperheads

>While a record (of a shared used dbf) is already locked can the *same* =
>user Rlock() the *same* record again?

For what purpose? I mean... if it's locked, it's locked, that is until
you issue a dbRUnLock().

Quote:
>Also is there a way to determine if a record is locked or not? I mean a =
>way other than:  IF rlock() ... e.t.c.

Assuming you're talking about Clipper 5.x, check out the dbRLockList()
function in the online help:

 DBRLOCKLIST() --> aRecordLocks

 Returns an array of the locked records in the current or aliased work
      area.

 DBRLOCKLIST() is a database function that returns a one-dimensional
     array that contains the identities of record locks active in the
     selected work area.



Sat, 19 May 2001 03:00:00 GMT  
 Rlock() wonder..
Actually, RLocking the same record repopulates the data buffers from disk -
so it is possible to loose uncommitted edits simply by RLocking the
currently locked record.


Quote:


>>>While a record (of a shared used dbf) is already locked can the *same* =
>>>user Rlock() the *same* record again?

>Yes.  That is to say, no harm done.

><snip>



Sat, 19 May 2001 03:00:00 GMT  
 Rlock() wonder..

Quote:


>>While a record (of a shared used dbf) is already locked can the *same* =
>>user Rlock() the *same* record again?

Yes.  That is to say, no harm done.

Quote:
>>Also is there a way to determine if a record is locked or not? I mean a =
>>way other than:  IF rlock() ... e.t.c.

>Assuming you're talking about Clipper 5.x, check out the dbRLockList()
>function in the online help:

> DBRLOCKLIST() --> aRecordLocks

> Returns an array of the locked records in the current or aliased work
>      area.

> DBRLOCKLIST() is a database function that returns a one-dimensional
>     array that contains the identities of record locks active in the
>     selected work area.

Beware that some RDDs (at least Comix) will return an empty array if
the file is USEd EXCLUSIVE, and you have also been calling RLOCK();
RLOCK() calls seem to be ignored and return .T. if a file is used
exclusive.

I use a simple function that attempts to write a field value back to
itself and traps the lock error:

================ snip ==================

/*
FUNCTION
   RecIsLocked() --> lrecIsLocked
DESCRIPTION
   Returns .T. if the current or specified record can be
   assigned, i.e. the file is USEd EXCLUSIVE, or a file or
   record lock is in place.
COMMENT
   Tests lock by attempting an assign within a SEQUENCE
*/
FUNCTION RecIsLocked()

LOCAL e                            // scope the error object

LOCAL lret := .T.                  // return value

LOCAL olderror := ;                // handle all errors within
 ERRORBLOCK( { |e| BREAK( e ) } )  // the SEQUENCE constructs

// now test the assign/lock

BEGIN SEQUENCE

   // assign the unchanged value of the last field back to
   // the last field -- this will fail if a lock is required.

   // Uses the last field to lessen the likelihood of
   // assigning an indexed or key field, with its attendant
   // overhead in updating the index file.

   // Note that some RDDs will GPF in protected mode if you
   // attempt to assign at EOF().

   FIELDPUT( FCOUNT(), FIELDGET( FCOUNT() ) )
   ERRORBLOCK( olderror )

RECOVER USING e

   // assignment failed
   lret := .F.
   ERRORBLOCK( olderror )

   // if other than "Lock Required" call the error handler
   IF !( e:subcode == 1022 )

      EVAL( olderror, e )

   ENDIF

END SEQUENCE

// return success
RETURN ( lret )



Sun, 20 May 2001 03:00:00 GMT  
 Rlock() wonder..

Quote:

>Actually, RLocking the same record repopulates the data buffers from disk -
>so it is possible to loose uncommitted edits simply by RLocking the
>currently locked record.

Hi,

Just out of curiosity, how do you edit the record without locking it, and
not get a "Lock required" message?

Alex



Sun, 20 May 2001 03:00:00 GMT  
 Rlock() wonder..
You can't.

If you'd read my post, you'd see that I said "RLocking the currently locked
record" - that means RLock - Edit - RLock (again)

Quote:


>>Actually, RLocking the same record repopulates the data buffers from
disk -
>>so it is possible to loose uncommitted edits simply by RLocking the
>>currently locked record.

>Hi,

>Just out of curiosity, how do you edit the record without locking it, and
>not get a "Lock required" message?

>Alex



Sun, 20 May 2001 03:00:00 GMT  
 Rlock() wonder..
On Wed, 2 Dec 1998 10:14:25 +0200, "Alex Schaft"

Quote:

>Just out of curiosity, how do you edit the record without locking it, and
>not get a "Lock required" message?

Don't actually edit the fields, but place the contents of the fields
into get variables, edit them, lock the record, write the updates back
to the record, then unlock. However, I prefer locking the record
*before* populating get variables. There are different schools of
thought on this, regarding to what's referred to as "lunch lock".


Sun, 20 May 2001 03:00:00 GMT  
 Rlock() wonder..
- thanks for any reply/suggestion. -

I attempted, recently,  to review/modify a code portion of an 'old' application which got on inconvenient results.
Here is (eh.. was!) the code which caused my post about rlock()...
..
IF select( "inve" ) == 0
    use inve shared new
ELSE
    select inve
ENDIF
SET INDEX TO inve           // .ntx file is ok!
inve->(DBGOTOP())          // 'cause for some reason, we want to update the first record in inve.dbf.
IF inve->(EOF())                 // no records in dbf?
   inve->(DBAPPEND())     // add a new one.  (while a new record appended this was the current and LOCKED record)
ENDIF
// follow some vars initialization.. and regular get statements..
// now go to replace fields
IF inve->(RLOCK())   //  Here comes the possible second rec. lock for the same record...
    REPLACE inve->Amount      WITH nAmount
        .....
    REPLACE inve->InsDate      WITH dInsDate      // last replace.
ELSE
       ErrorTone()

ENDIF
...
result: No replace was taking place, the only thing was just an empty record in the inve.dbf  .
(but If i tried it again, the second time it was ok, of course because no append was performed and so no double rlock..)

Well, the above code it's obvious that doesn't claim any prize (indeed, it was 'bad code' and it is already 'past'...(that is, rewritten)) but the question is still pending. What was actually wrong? I suspect that the problem was the twice Rlocking... (while I can't imagine something else).

--
Pit V



Sun, 20 May 2001 03:00:00 GMT  
 Rlock() wonder..
Hi Pit,

Quote:

>..
>IF select( "inve" ) == 0
>    use inve shared new
>ELSE
>    select inve
>ENDIF
>SET INDEX TO inve           // .ntx file is ok!
>inve->(DBGOTOP())          // 'cause for some reason, we want to update the first record in inve.dbf.
>IF inve->(EOF())                 // no records in dbf?
>   inve->(DBAPPEND())     // add a new one.  (while a new record appended this was the current and LOCKED record)

Here dbappend() is not guaranteed success.

Quote:
>ENDIF
>// follow some vars initialization.. and regular get statements..
>// now go to replace fields
>IF inve->(RLOCK())   //  Here comes the possible second rec. lock for the same record...

If dbappend() fails - you end up with locking the eof() record ! The
NG said that an attempt to rlock() en empty dbf returns true !

Quote:
>    REPLACE inve->Amount      WITH nAmount
>        .....
>    REPLACE inve->InsDate      WITH dInsDate      // last replace.
>ELSE
>       ErrorTone()

>ENDIF
>...
> I suspect that the problem was the twice Rlocking... (while I can't imagine something else).

How about verifying your code once again, this time by checking
neterr() after dbappend() ?

--
Bambang P
Semarang 50144
Central Java
Indonesia.
----
Author of:
 FBrowse  - General browser class for Force Language
 MakForce - Powerful and Intuitive Make utility for almost any language
 <http://force.szolnex.hu/pages/download/ftphigh.htm>
----
Send private messages to bpranoto at indosat dot net dot id



Mon, 21 May 2001 03:00:00 GMT  
 Rlock() wonder..
Hi Pit,

Quote:

>..
>IF select( "inve" ) == 0
>    use inve shared new
>ELSE
>    select inve
>ENDIF
>SET INDEX TO inve           // .ntx file is ok!
>inve->(DBGOTOP())          // 'cause for some reason, we want to update the first record in inve.dbf.
>IF inve->(EOF())                 // no records in dbf?
>   inve->(DBAPPEND())     // add a new one.  (while a new record appended this was the current and LOCKED record)

Here dbappend() is not guaranteed success.

Quote:
>ENDIF
>// follow some vars initialization.. and regular get statements..
>// now go to replace fields
>IF inve->(RLOCK())   //  Here comes the possible second rec. lock for the same record...

If dbappend() fails - you end up with locking the eof() record ! The
NG said that an attempt to rlock() en empty dbf returns true !

Quote:
>    REPLACE inve->Amount      WITH nAmount
>        .....
>    REPLACE inve->InsDate      WITH dInsDate      // last replace.
>ELSE
>       ErrorTone()

>ENDIF
>...
> I suspect that the problem was the twice Rlocking... (while I can't imagine something else).

How about verifying your code once again, this time by checking
neterr() after dbappend() ?

--
Bambang P
Semarang 50144
Central Java
Indonesia.
----
Author of:
 FBrowse  - General browser class for Force Language
 MakForce - Powerful and Intuitive Make utility for almost any language
 <http://force.szolnex.hu/pages/download/ftphigh.htm>
----
Send private messages to bpranoto at indosat dot net dot id



Tue, 22 May 2001 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. How many RLock()s per file under S'87

2. multiple Rlocks()

3. Different offsets for rlock in comix vs. six3

4. How to rlock 2 records ?

5. Any problems using multiple RLOCK()'s?

6. Data corruption from failed rlock()

7. RLOCK() Problem Win95/NetWare 3.12

8. Crystal Reports and Rlocks CA-clipper

9. RLock() on Netware over NT Gateway

10. Rlock Error !

11. Rlock()

12. rlock() and dbunlock() in Replaceing DBF

 

 
Powered by phpBB® Forum Software