We have the following problem with record locks in browse lists:

when a user creates a browse list, for example by using / in a screen,

or with any other method (popups), and the user browses through the list, changes and saves a record, then this record will sometimes keep its lock.

This happens often, but we can not predict the exact circumstances.

We are using Novell 4.11 and Arev 3.12 with then NLM 1.12 .

The workstations are running onder dos 6.2 .

This has become such a serious problem that we had to split our materials database in two, in a definitions part and a part that stores data that are continously updated.

Andre van Hooren

This is a bug in every version of Arev that I have tried it on. I reported it when 2.12 was just released, but it has appeared in all releases through 3.12. Here are the circumstances:

* Your browse list is a LATENT list.

* It evaluates to something other than the complete file (in other words, SELECT filename LATENT is insufficient to duplicate the problem – it must be SELECT filename WITH something LATENT)

* Locks are set correctly as you go through the list, but are not released properly.

Victor, thank you for reacting so quickly.

What I don't understand about your explanation is the LATENT condition. Any browse list can (but need not) have this problem.

When you make a list, you can have a resolved or a noresolved list as long as it is not on an indexed column. You can use this list doing a 'Edit file' command, and the list will stay as it is (being 'RES' or 'res' in the status line. But starting a window form a TCL list is only possible from a resolved list. Using a latent list and then a command like 'Window window.name' will result in "RTP27 File has not been opened" error. Besides, when making a browse list from within a window, for example by going into query mode, this will result in a resolved list being executed by Arev, after which the list is put in the browse list, and no active list is visible anymore (@LIST.ACTIVE=0). So what is a browse list anyway but a list of keys in a common variable?

I also get the impression from your reaction, that nobody at RTI has tried to solve it. Is this problem so hard to crack?

For us the problem is, that there is no work-around, and we have to change our database structure - no small thing.

Andre van Hooren

What I don't understand about your explanation is the LATENT condition.

I know it doesn't exactly fit your scenario, but it's the only situation I've been able to duplicate the problem with in every case. I wanted to create something that was readily reproducible so that I could give clear instructions when reporting the bug.

Any browse list can (but need not) have this problem.

Since I discovered the conditions resulting in the error as described in my previous post, I've been unable to duplicate the problem any other way. Can you describe the architecture of your file a bit? Maybe that has something to do with it. What do your keys look like? What network driver are you using? Etc.

But starting a window form a TCL list is only possible from a resolved list. Using a latent list and then a command like 'Window window.name' will result in "RTP27 File has not been opened" error.

You learn something new every day.

Besides, when making a browse list from within a window, for example by going into query mode, this will result in a resolved list being executed by Arev, after which the list is put in the browse list, and no active list is visible anymore (@LIST.ACTIVE=0). So what is a browse list anyway but a list of keys in a common variable?

Good point. I've never encountered the problem under these conditions, though, at least not that I'm aware of.

I also get the impression from your reaction, that nobody at RTI has tried to solve it. Is this problem so hard to crack?

Well, I showed it to the tech guys at the conference in San Fransisco a few years ago, and they put it on their to-do list.

For us the problem is, that there is no work-around, and we have to change our database structure - no small thing.

Have you thought about doing anything with MFSs? Suppose, for example, that you don't care if there is a lock already on a record as long as it was set by the current workstation. You could have the MFS act like a lock was set when in fact no lock was set at all. Perhaps even better, you could use the MFS to audit what activities caused what I/O in what order by whom and by which processes.

Victor, in response to your remark about using MFSs:

"Have you thought about doing anything with MFSs? Suppose, for example, that you don't care if there is a lock already on a record as long as it was set by the current workstation. You could have the MFS act like a lock was set when in fact no lock was set at all. Perhaps even better, you could use the MFS to audit what activities caused what I/O in what order by whom and by which processes."

The locks are visible all over the netwerk. The original file that had this problem stored all the component-detail-info of our order entry, and is the most frequently addressed of all files. We simply had to split it in a front-end definitions part and a back-end variable data end, that has no entry screen.

We are using MFSs quite a lot, in fact, all of our processing is done by MFS, so much we have to be careful not to add more MFS functionality in case MFSs start calling each other (detail records can call main records, which have also MFSs that must never call de detail-records etc.).

The remaining files having this problem are used mainly as lookup tables with only single-user data entry, so they could benefit from entry screens that do no locking at all.

The lookup tables need no MFS, but an MFS could be added just for analysis of the locking problems. Maybe we can try to add code to some post-window-process that looks for locks and can unlock records.

Thank you again for responding.

Andre van Hooren

Well, I showed it to the tech guys at the conference in San Fransisco a few years ago, and they put it on their to-do list.

That you did, and you know what? It must never have been entered in and I forgot all about it until after 3.12 shipped. I can't see how I would have looked at that and ignored it. Shouldn't have been that hard to fix.

akaplan@sprezzatura.com

Sprezzatura, Inc.

View this thread on the forum...