I dialed into a client site late last night at to do some updating to some dicts. I will do this because the dict is constantly locked during operating hours (read - can this be changed in the future).

The client is running Novell 5.? and the proper LH.NLM and the proper drivers for OI and AREV.

The problem was that the dict was still locked. I went to the NLM_STATS and checked for users. There was myself and two others.

The stats didn't indicate any exclusive locks on the dict but a couple on the table.

I emailed the user and got a response this morning that they had logged out 3 hours before I was connected.

We have had alot of issues at this site and I am curious about this situation. Does anyone have any insight or similar situations or am I missing anything simple.

Thanks

What do you mean, the dict was locked? RTP57 based record locks? RTP57 based file locks? OS level file locks?

The Sprezzatura Group

[i]Celebrate CeBIT with Sprezz Local![/i]

Well its been a few days so I can't remember the exact type of lock.

Basically, when I try to go in to make a change to a dict then save I get the "unable to save" msg. This happens alot, my limited understanding is that the dicts get locked because of btree,xref etc issues when someone has a form open that is bound to the file.

(This is a problem also because I can do it through AREV but I want to do it through OI)

So, I went into the system after hours. I tried to make a change to the dict and it wouldn't let me. I was curious to see who was logged in so I looked at the NLM_STATS. The stats reported that 1 other user was in. I refreshed and they were still reported in a had the table assigned.

I inquired the next morning and the user said that they had logged out of the app. 4 hours before I had gone in. We have had alot of

network issues at this site and need to follow this up.

Thanks

If this is an OI problem, it's not that the system locks dicts brecause of indexing. ARev used to place a file lock on the DICT file to try and prevent people from change the dictionary out from under you while you're modifying the form.

OI creates a DICT.TEMP_FileName program to handle this locking. The table builder does not allow access if it detects the DICT.TEMP_FileName is already there.

What you'll need to do is delete the offending files. Be sure to check that they are not in the DBT file as well.

The Sprezzatura Group

[i]Celebrate CeBIT with Sprezz Local![/i]

Hmmm, I would assume you are correct.

Thanks alot I will look into that further.

Well there is no DICT.TEMP_tablename for that table as looked for using the system editor. I am the only one able to get in as developer.

View this thread on the forum...