problems in 28.1

S

sreekuax

Member
Hi all Say am in 28.1 with a batch # and voucher #. my connection goes and am login to eb2 again.. but if i give the same batch # and Voucher # - its telling me a message that the record is in use and press ctrl-c to stop..!!! This seems to be weird is it ike that i can never ever work on that voucher and batch Id again ???? Please help

error message : ba_mstr in use by on tty ?. Wait or press CTRL-C to stop. (121)
 
The message tells you that there is a locking conflict. Another user is holding a lock on the record you try to fetch with a share or an exclusive lock. If the application is utilizing a pessimistic locking strategy, or even worse, is working with share locks, this is "classic" application behavior. The only solution is for the user who is holding the lock to release the lock. Usually such behavior occurs when the application utilizes pessimistic locking and a user presses the update button and the leaves, for a coffee break ... or for good ( just kidding ).

First you should tell the user to release the lock in either committing or rolling back his work.

But, if you are certain, that the user does not lock the record anymore, then most likely the lock is still there because the client process disappeared from the database without the database recognizing it. If this was a remote client then the database depends on the TCP/IP keep alive to recognize the disappeared client. The default for this is 30 minutes on most system I know. If this was a self-service client then most likely the watchdog is not running which is responsible to clean-up resources held be these types of clients.

If nothing else does help you need to restart the database - this will clear the lock table effectively ...


I should point out that I have no knowledge about MFG/PRo whatsoever - this is generic Progress knowledge.

Heavy Regards, RealHeavyDude.
 
RealHeavyDude said:
The message tells you that there is a locking conflict. Another user is holding a lock on the record you try to fetch with a share or an exclusive lock. If the application is utilizing a pessimistic locking strategy, or even worse, is working with share locks, this is "classic" application behavior. The only solution is for the user who is holding the lock to release the lock. Usually such behavior occurs when the application utilizes pessimistic locking and a user presses the update button and the leaves, for a coffee break ... or for good ( just kidding ).

First you should tell the user to release the lock in either committing or rolling back his work.

But, if you are certain, that the user does not lock the record anymore, then most likely the lock is still there because the client process disappeared from the database without the database recognizing it. If this was a remote client then the database depends on the TCP/IP keep alive to recognize the disappeared client. The default for this is 30 minutes on most system I know. If this was a self-service client then most likely the watchdog is not running which is responsible to clean-up resources held be these types of clients.

If nothing else does help you need to restart the database - this will clear the lock table effectively ...


I should point out that I have no knowledge about MFG/PRo whatsoever - this is generic Progress knowledge.

Heavy Regards, RealHeavyDude.
Click to expand...

Hi Bro :

I agree that its a record lock - but see the scenario below :

1. i am logged in - i was only using 28.1 and connection gone
2. am login in - going to 28.1 putting last batch # and Vo # which i was using in my last session - the system gives this error telling its locked...
so here my id is having a lock...
3. sometimes am getting that not ba_mstr but apc_ctrl is locked and it doesnt give me a batch ID !!!! now whats happening here ????
 
If I understand you correct:

  • You loose the connection amidst a transaction on a record.
  • After re-connecting and trying to repeat the transaction on the very same record you get the error message that it's locked.
To me that indicates that the database has not recognized that you lost connection in the first place. This can happen for various reasons, mostly it's the infamous TCP/IP keep alive mechanism which is utilized by the database to detect disappeared connections. If that's the case you have 2 options:

  1. Wait until the TCP/IP keep alive timeout is reached and the database recognizes the lost connection and removes the offending lock from the lock table.
    • If the lock is not removed by then then the database will never recognize that the connection disappeared as long as it is running. I've seen this behavior some times in the past. The only remediation I am aware of is option 2.
  2. Restart the database ( which will effectively wipe the lock table ).
Heavy Regards, RealHeavyDude.
 
I am familiar with certain other locking problems with MFG/Pro.
I have written an utility to request user information in relation to userid, operating system information.
Send me a mail and I wil send you the program.

William
 
another interesting issue with 28.1 !!!!
Its accepting two lines as 1 or say 2..28_1issue.JPG

means in line i entered data for line 1 and going to next line and unknowingly entering line 1 again the system is accepting !!!! why is this happening ???/
 
The thing is that you can keep on changing existing lines, until the voucher is confirmed on the last screen.
This is a documented feature because in other companies you have users who enter voucher and others who confirm the vouchers.

W
 
You must log in or register to reply here.
Back
Top