Any problems using multiple RLOCK()'s? 
Author Message
 Any problems using multiple RLOCK()'s?

Your code should only need to have one rlock() per usage of a record.
Once you've determined a lock is successful (using an IF conditional),
then any functions called should assume a locked record. I've never
bothered to consider how many times an rlock() can be attempted against
one record because it is redundant.



Quote:
> Hi all!
> I've inherited a v5.2d compiled Clipper app and it is used on a Novell
> Network.  I'm trying to figure out why EOF markers magically appear in
> DBF files before the real EOF is encountered.  The DBFs are opened and
> is read-only by 40+ users.  A "server" workstation has FLOCKs on all
> the primary factory DBFs and is the only "user" that can modify the
> records.  Users issue requests to the server via a request database
> which they can update (obviously).

> My question is:  Is there any problem with multiple rlocks on the same
> record??  Is there a lock table that can eventually get filled up??
> Any help would be greatly appreciated.

> --  Earl Riggs

> P.S. The relevent server code portion in question appears below....

> procedure One
>    select Request_DBF
>    goto My_Record
>    if rlock()
>        Perform_Request()
>    endif
> return

> procedure Perform_Request
>    select Another_DBF
>       .
>       <do stuff>
>       .

>    select Request_DBF // Remember, record should already be locked
>    rlock()                       // Second lock command on same record
>    replace THIS with THAT  // single character request codes
>    commit
>    unlock

> return

> ERiggs from {*filter*}ia, USA using VO 2.0b4


> you must first remove "all-doubt."

Sent via Deja.com http://www.*-*-*.com/
Before you buy.


Mon, 01 Apr 2002 03:00:00 GMT  
 Any problems using multiple RLOCK()'s?
I'd suggest upgrading to 5.2E which is FREE, 5.2d has known problems with
record locking...

Visit Computer Associates at http://www.*-*-*.com/


Quote:
> Hi all!
> I've inherited a v5.2d compiled Clipper app and it is used on a Novell
> Network.  I'm trying to figure out why EOF markers magically appear in
> DBF files before the real EOF is encountered.  The DBFs are opened and
> is read-only by 40+ users.  A "server" workstation has FLOCKs on all
> the primary factory DBFs and is the only "user" that can modify the
> records.  Users issue requests to the server via a request database
> which they can update (obviously).

> My question is:  Is there any problem with multiple rlocks on the same
> record??  Is there a lock table that can eventually get filled up??
> Any help would be greatly appreciated.

> --  Earl Riggs

> P.S. The relevent server code portion in question appears below....

> procedure One
>    select Request_DBF
>    goto My_Record
>    if rlock()
>        Perform_Request()
>    endif
> return

> procedure Perform_Request
>    select Another_DBF
>       .
>       <do stuff>
>       .

>    select Request_DBF // Remember, record should already be locked
>    rlock()                       // Second lock command on same record
>    replace THIS with THAT  // single character request codes
>    commit
>    unlock

> return

> ERiggs from {*filter*}ia, USA using VO 2.0b4


> you must first remove "all-doubt."



Tue, 09 Apr 2002 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. multiple Rlocks()

2. Using DLL's or CIN's to talk to multiple Ethernet cards

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

4. RLOCK() Problem Win95/NetWare 3.12

5. Unresolved External...using Multiple dll's

6. J3 problem using wd 'wait'

7. multiple regression using AWK Problem

8. Design problem using Multiple Dispatch or Redispatch (long)

9. Problem using MULTIPLE FUNCTIONS in mySQL/php query

10. using date('B',int) in a loop problem

11. Problem compiling 'ns' using tcl7.6

12. Multiple Dispatch (was Re: Replacing Multiple Inheritance with Java's Interfaces)

 

 
Powered by phpBB® Forum Software