Lock Failed error in Clipper 5.2 app 
Author Message
 Lock Failed error in Clipper 5.2 app

I have an Order Processing app in Clipper 5.2, it has been in use since
about 1990 in Clipper Summer 87.  In March & April 2001, I completed the
conversion to Clipper 5.2e, and have been having strange problems.

When creating new records, users are getting messages from our custom error
system stating the following
DBFNTX/1035
Code 41: Lock Failure
DBCOMMIT (0)
NETAPP (300)

where "NetApp" is one on my routines.  The user has the option of retrying,
and 9 out of 10 times is successful, the 1 out of ten time they may need to
retry twice, but it still works.

When I found a note on the internet somewhere about this being a problem
when using a custom error handler, and the "solution" of causing the error
to by ignored, my users started getting one line DBCOMMIT errors and getting
thrown out of the application, and losing data in the process.  I tried
adding a delay in the error handler before returning control, thinking it
would simulate the user reading the screen and pressing R for retry, but
with no success.

I am suspecting network cable problems, because the users will go for up to
an hour with no messages and then get a bunch all at the same time.  There
are generally about 16-20 users in the application at a time, on a network
with 175-225 users on it.

This is getting very frustrating for my users and myself, any suggestions
would be greatly appreciated.

--
Barry H. Greene
Providing Excellence through Technology
Stoughton, MA  USA
Voice: 781-436-DATA (3282)
Fax: 781-344-8107

Web: www.ProvidingExcellence.com



Tue, 02 Dec 2003 23:42:36 GMT  
 Lock Failed error in Clipper 5.2 app

Quote:
>When creating new records, users are getting messages from our custom error
>system stating the following
>DBFNTX/1035

From the (Clipper5.3) NG:

 DBFNTX/1035  Record lock timeout

     Explanation:  The request for a record lock has timed out.

     Action:  Make sure that the maximum file locks for the OS has not
     been exceeded.  This can be caused by using DBRLOCK() and not using
     DBRUNLOCK() to release record locks.

Quote:
>When I found a note on the internet somewhere about this being a problem
>when using a custom error handler, and the "solution" of causing the error
>to by ignored, my users started getting one line DBCOMMIT errors and getting
>thrown out of the application, and losing data in the process.  I tried
>adding a delay in the error handler before returning control, thinking it
>would simulate the user reading the screen and pressing R for retry, but
>with no success.

You can't ignore this error!  How can you write to the record if it
isn't locked?

If the lock is usually successful within 2 retries, I would recommend
changing your error handler so that it simply retries automatically up
to 3 times (possibly with a delay if necessary) before reporting the
error to the user.

You're probably right that it is a network problem, and therefore should
be trying to fix the cause anyway.

--
Douglas Woodrow



Wed, 03 Dec 2003 01:45:20 GMT  
 Lock Failed error in Clipper 5.2 app
It actually doesn't just happen on the appends, it also occurs on some
"dbcommits".
I did find an earlier thread about this exact issue, and it reference the
file NTXERR.PRG in the sample source that comes with Clipper 5.2
I am going to implement the solution from that thread on Monday morning
while I am actually spending the day at this client site.


Quote:

> >When creating new records, users are getting messages from our custom
error
> >system stating the following
> >DBFNTX/1035

> From the (Clipper5.3) NG:

>  DBFNTX/1035  Record lock timeout

>      Explanation:  The request for a record lock has timed out.

>      Action:  Make sure that the maximum file locks for the OS has not
>      been exceeded.  This can be caused by using DBRLOCK() and not using
>      DBRUNLOCK() to release record locks.

> >When I found a note on the internet somewhere about this being a problem
> >when using a custom error handler, and the "solution" of causing the
error
> >to by ignored, my users started getting one line DBCOMMIT errors and
getting
> >thrown out of the application, and losing data in the process.  I tried
> >adding a delay in the error handler before returning control, thinking it
> >would simulate the user reading the screen and pressing R for retry, but
> >with no success.

> You can't ignore this error!  How can you write to the record if it
> isn't locked?

> If the lock is usually successful within 2 retries, I would recommend
> changing your error handler so that it simply retries automatically up
> to 3 times (possibly with a delay if necessary) before reporting the
> error to the user.

> You're probably right that it is a network problem, and therefore should
> be trying to fix the cause anyway.

> --
> Douglas Woodrow



Wed, 03 Dec 2003 03:54:41 GMT  
 Lock Failed error in Clipper 5.2 app

Quote:
>DBFNTX/1035
>Code 41: Lock Failure

If your customer is using a NetWare network, there are probably lock error
messages on the NetWare console that correspond to the Clipper errors. If
this is the case, then one solution is to have the network administrator
permanently increase the maximum number of record locks, the maximum number
of record locks per session, the maximum number of file locks, and the
maximum number of file locks per session on the NetWare server.


Wed, 03 Dec 2003 13:51:40 GMT  
 Lock Failed error in Clipper 5.2 app
Barry,

If you are not using the Multiple Record Lock features of the 5.x RDD
system, you could always "redirect" the application source to utilize
the functions contained in LOCKS.PRG & further adjust to force Lock /
Unlock a given record, sample RLOCKFIX.CH and LOCKS.PRG excerpt
(included w/ 5.2(e)) are included below.

To implement:
-------------
Cut n' Paste RLOCKFIX.CH to a file,
Cut n' Paste LOCKS.PRG excerpt to a file (ex: MYLOCKS.PRG),

Add:  #include "RLOCKFIX.CH" to each program using
      RLOCK(), APPEND BLANK, UNLOCK,

Include (add) "MYLOCKS.PRG" in the source code compile / link cycle.

What it does:
-------------
RLOCKFIX.CH translates RLOCK() and APPEND BLANK to functions
containing enhanced retry code RECLOCK() and ADDREC().

RECLOCK() function adjusted to attempt specific record lock by record
number, DBRLOCK( RECNO() ).

UNLOCK is translated to release *all* records locks for the currently
selected workarea (Database) .

------------
I ran into the same problem with an app. converted from S'87 several
years back, on advice (at that time) from David Lyon of [CA] I
implemented this fix, which corrected the problem.

You mentioned the NTXERR.PRG mod., in conjunction with that you may
want to carefully review all modules in the app. to ensure Index files
are being opened for a given Database in exactly the same order in
each module, this to prevent a potential "deadly embrace" condition

module 1:
USE ANIMALS INDEX CAT, DOG, BIRD, FISH

module 2:
USE ANIMALS INDEX DOG, CAT, BIRD, FISH


different wkstns, neither wkstn. would be able to release the (Index
file) lock.  This may also manifest itself as a 1035 error in certain
situations, IIRC.

* Not saying this is the case here, just an item to consider.

-----------------
If the Server in question is Novell Netware, David's suggestion would
be the first item to try, that alone may effect a solution.  If not,
and if the app. is filling up the Server lock table, this approach may
help.

I hope the info. helps.

Regards,
Bob

// ------- snip ------------

// -----------
// RLOCKFIX.CH
// -----------
/*
 below translate commands fix rlock() problem on
 child databases used with SET RELATION ... for Clipper 5.2(c)
*/

#xtranslate RLOCK()             => RecLock(5)
#xcommand   APPEND BLANK        => AddRec(5)
#xcommand   UNLOCK              => DBRUNLOCK()

// eof: RLOCKFIX.CH

// ------- snip ------------

// -----------------------------------------------
// LOCKS.PRG - ADDREC() and RECLOCK() functions ..
// -----------------------------------------------
/***
*
*  Locks.prg
*  Sample network functions to supplant USE, FLOCK(), RLOCK() and
*  APPEND BLANK.
*
*  Copyright, Nantucket Corporation, 1989, 1990
*
*  Compile as follows:
*    
*         C>CLIPPER Locks /N /W /A /M
*/

#include "Common.ch"  // for DEFAULT function...

/***
*  AddRec( <nseconds> ) --> lSuccess
*  Attempt to APPEND BLANK with optional retry
*/
FUNCTION AddRec( nSeconds )
   LOCAL lForever

   DEFAULT nSeconds TO 0

   APPEND BLANK
   IF .NOT. NETERR()
      RETURN (.T.)
   ENDIF
   lForever = (nSeconds = 0)
   DO WHILE (lForever .OR. nSeconds > 0)
      APPEND BLANK
      IF .NOT. NETERR()
         RETURN (.T.)
      ENDIF
      INKEY(.5)         // Wait 1/2 second
      nSeconds  = nSeconds  - .5
   ENDDO
   RETURN (.F.)         // Not locked

/***
*  RecLock( <nSeconds> ) --> lSuccess
*  Attempt to RLOCK() with optional retry
*/
FUNCTION RecLock( nSeconds )
   LOCAL lForever

   DEFAULT nSeconds TO 0

   IF DBRLOCK( RECNO() )   // RLOCK()
      RETURN (.T.)         // Locked
   ENDIF

   lForever = (nSeconds = 0)

   DO WHILE (lForever .OR. nSeconds > 0)
      IF DBRLOCK( RECNO() )   // RLOCK()

         RETURN (.T.)     // Locked
      ENDIF

      alltrim(str(nSeconds))
      INKEY(.5)           // Wait 1/2 second
      nSeconds = nSeconds - .5
   ENDDO


RETURN (.F.)           // Not locked

Quote:

> I have an Order Processing app in Clipper 5.2, it has been in use since
> about 1990 in Clipper Summer 87.  In March & April 2001, I completed the
> conversion to Clipper 5.2e, and have been having strange problems.

> When creating new records, users are getting messages from our custom error
> system stating the following
> DBFNTX/1035
> Code 41: Lock Failure
> DBCOMMIT (0)
> NETAPP (300)

> where "NetApp" is one on my routines.  The user has the option of retrying,
> and 9 out of 10 times is successful, the 1 out of ten time they may need to
> retry twice, but it still works.

> When I found a note on the internet somewhere about this being a problem
> when using a custom error handler, and the "solution" of causing the error
> to by ignored, my users started getting one line DBCOMMIT errors and getting
> thrown out of the application, and losing data in the process.  I tried
> adding a delay in the error handler before returning control, thinking it
> would simulate the user reading the screen and pressing R for retry, but
> with no success.

> I am suspecting network cable problems, because the users will go for up to
> an hour with no messages and then get a bunch all at the same time.  There
> are generally about 16-20 users in the application at a time, on a network
> with 175-225 users on it.

> This is getting very frustrating for my users and myself, any suggestions
> would be greatly appreciated.



Thu, 04 Dec 2003 11:53:31 GMT  
 Lock Failed error in Clipper 5.2 app
We had a similar problem with a similar number of users. If you are using
Novel there is a setting Max number of Record locks. We had it set to 20,000
I think. The problem was cured when it was set to the maximum 100,000.


Quote:
> I have an Order Processing app in Clipper 5.2, it has been in use since
> about 1990 in Clipper Summer 87.  In March & April 2001, I completed the
> conversion to Clipper 5.2e, and have been having strange problems.

> When creating new records, users are getting messages from our custom
error
> system stating the following
> DBFNTX/1035
> Code 41: Lock Failure
> DBCOMMIT (0)
> NETAPP (300)

> where "NetApp" is one on my routines.  The user has the option of
retrying,
> and 9 out of 10 times is successful, the 1 out of ten time they may need
to
> retry twice, but it still works.

> When I found a note on the internet somewhere about this being a problem
> when using a custom error handler, and the "solution" of causing the error
> to by ignored, my users started getting one line DBCOMMIT errors and
getting
> thrown out of the application, and losing data in the process.  I tried
> adding a delay in the error handler before returning control, thinking it
> would simulate the user reading the screen and pressing R for retry, but
> with no success.

> I am suspecting network cable problems, because the users will go for up
to
> an hour with no messages and then get a bunch all at the same time.  There
> are generally about 16-20 users in the application at a time, on a network
> with 175-225 users on it.

> This is getting very frustrating for my users and myself, any suggestions
> would be greatly appreciated.

> --
> Barry H. Greene
> Providing Excellence through Technology
> Stoughton, MA  USA
> Voice: 781-436-DATA (3282)
> Fax: 781-344-8107

> Web: www.ProvidingExcellence.com



Fri, 05 Dec 2003 12:14:22 GMT  
 Lock Failed error in Clipper 5.2 app
I tried several different things including the code in NTXERR.prg, but with
no success.  I finally gave up on using the Custom Error Sys, and the
problem went away as soon as I relinked with the standard errorsys!!!  This
made no sense but, this is Clipper we're talking about.

--
Barry H. Greene
Providing Excellence through Technology
Stoughton, MA  USA
Voice: 781-436-DATA (3282)
Fax: 781-344-8107

Web: www.ProvidingExcellence.com



Tue, 09 Dec 2003 09:09:29 GMT  
 Lock Failed error in Clipper 5.2 app

Quote:
>I tried several different things including the code in NTXERR.prg, but with
>no success.  I finally gave up on using the Custom Error Sys, and the
>problem went away as soon as I relinked with the standard errorsys!!!  This
>made no sense but, this is Clipper we're talking about.

I just caught the tail end of this discussion. I had same problem with lock
failures after putting in a cusomer error handler. I did get the problem fixed
- had to retry forever, which is what standard error system does. Also, may
have to chain back to ntxerr after seeing this error. I'm sure I have notes on
how to do this if you need it. It may also be in FAQ.

Irv



Sun, 14 Dec 2003 20:26:09 GMT  
 Lock Failed error in Clipper 5.2 app
Thanks, I would be interested in any other details you have to offer, for
the time being, I have just removed the custom handler from that part of the
application.

--
--
Barry H. Greene
Providing Excellence through Technology
Stoughton, MA  USA
Voice: 781-436-DATA (3282)
Fax: 781-344-8107

Web: www.ProvidingExcellence.com


Quote:
> >I tried several different things including the code in NTXERR.prg, but
with
> >no success.  I finally gave up on using the Custom Error Sys, and the
> >problem went away as soon as I relinked with the standard errorsys!!!
This
> >made no sense but, this is Clipper we're talking about.

> I just caught the tail end of this discussion. I had same problem with
lock
> failures after putting in a cusomer error handler. I did get the problem
fixed
> - had to retry forever, which is what standard error system does. Also,
may
> have to chain back to ntxerr after seeing this error. I'm sure I have
notes on
> how to do this if you need it. It may also be in FAQ.

> Irv



Sat, 27 Dec 2003 09:58:35 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. error 19 in clipper 5.2 app Help!!

2. locking tables clipper 5.2

3. Clipper 5.2/Windows locking wierdness

4. How to Set Cap Lock Off/On in Clipper 5.2

5. Making Clipper 5.2 Apps Y2K Compliant

6. NT Printing Slow From Clipper 5.2 App

7. migration of 5.2 clipper app from netware 3.11 to netware 5

8. Building Win-apps with Clipper 5.2: best lib?

9. Clipper 5.2 app hanging up on novell 3.12

10. Clipper 5.2 apps running under Windows

11. clipper 5.2 apps and os/2

12. Corruption Detected Error on NTX with 2 versions of Clipper 5.2

 

 
Powered by phpBB® Forum Software