I'm working on an AREV 3.12 application. I've got a user on a particular screen that does a Ctrl-F10 (Browse Options) to create an active browse list within the window. Where you can do an Alt-I (Browse Edit) to see the list of keys. The user does his thing with the window and rows and then gets out of the window and back to the menu we have in our application. He doesn't do anything strange. What he's finding is that the rows are still locked.

A different user in a different session can try to bring up one of the rows he just dealt with but gets a message saying the row is locked. Even thru a different window but it's attached to the same table. We can do the same sort of thing in creating an active browse list thru the other screen but there isn't any locking problems.

I've compared the two windows and looked at the code behind the two windows and their prompts and haven't found anything to even hint at why one doesn't unlock the row and the other does. I've tried to recreate the problem in our development area but so far no success. I've checked the locking related AREV configurations for Environment and Workstation between the development area and the live area and didn't find any difference. I've been unsuccessful at finding anything in this discussion area to help.

If anyone can point me in the right direction, that would be a big help.

Thanks,

Michael Slack

Are you relying on built-in locking logic, or did you roll your own?

Hello:

Basically, for both screens we are using build in locking. Paint the window, click on the ADVANCED menu item and then CUSTOMIZE in the drop down menu. On the LOCKING prompt we use the "X" option for Exclusive Lock.

I've double checked both of the windows and the supporting subroutines and we do have some other tables that we call our own locking subroutine for but it's just a wraper for the native AREV LOCK and UNLOCK commands so we can add information messages to the screen as needed. So, no we haven't rolled our own locking.

The only difference I've found so far is in the subroutine behind the window that isn't letting go of the locks is an UNLOCK ALL command in the main driver routine right before the RETURN command. Both main modules look something like this (this being just a template). The CURRENT_SUB contains the argument from the subroutine call from behind the window.

CURRENT_SUB_LIST =ROUTINE1,ROUTINE2,"

CURRENT_SUB_LIST := "ROUTINE3,ROUTINE4, ROUTINE5"

LOCATE CURRENT_SUB IN CURRENT_SUB_LIST USING "," SETTING POS THEN

ON POS GOSUB ROUTINE1,ROUTINE2,ROUTINE3,ROUTINE4,ROUTINE5

END ELSE

MSG('ERROR: SUBROUTINE NOT FOUND|':CURRENT_SUB,MSG_MAP_A,'','')

END

RETURN

I'm still assuming that the UNLOCK ALL command in the main module of the subroutine of the screen that is keeping the rows locked isn't the root of the problem. It would seem to indicate that the UNLOCK ALL isn't working for some reason.

I hope this answers your question.

Thanks,

Michael Slack

Michael

For what it's worth, we too have Arev 3.12 and use the Exclusive locking from our arev windows.

I can't make problem occur when I try your user's steps.

If you can make a very simple window that is bound to the table in question and try out your user's steps. It might help you determine if this a r/basic code issue or an arev window issue.

Also is there an mfs on the table? Maybe the mfs is 'helping' out with a lock somewhere.

Taking a long shot;

Are you sure it's hitting unlock all before return? That would be the first thing I'd check. I would place a message right before unlock all/ return. If you don't see the message, then it's getting lost in one of the subroutines.

David Craig.

Thanks for everyone's help. I asked the user to reproduce the problem so I could see if there was something I was missing or doing differently in my attempts to recreate the problem in my development area. He was unable to reproduce the problem and has suggested that we table this problem for now. I plan on keeping an eye out for this problem. I might just stumble across it at some point.

Thanks,

Michael Slack

I'd be somewhat concerned about the UNLOCK ALL statement. Using UNLOCK ALL is desperation time as it will unlock stuff that shouldn't be unlocked at that moment.

Chances are they've had this problem before and a previous developer added the UNLOCK ALL out of desperation.

Hello Warren:

You're right, it's a concern and something I'll have to keep in mind for anything dealing with this particular screen and its code or any other.

Thanks,

Michael Slack

View this thread on the forum...