I have a client who is using Novell IntranetWare Client for Windows 95, Windows 95 workstations, NLM 1.5b, and OpenInsight 3.7.2. The connections are Citrix and T1 lines. They have a dedicated indexer that stops indexing approximately 1-2 times a day. The Index Server just lists an index file and field with no progress. Through NLM stats, I find that another user has a lock on the INDEX_COL*ROOT in the index file. It is a different user each time and last two times were both on the T1 lines not Citrix. Once we have the user with the lock reboot, the indexer starts indexing again. We have background indexing turned off but it appears that the stations still lock the index row when running a select statement on an indexed column. The select statements are used to retrieve a list of keys for a popup of rows. I tested using the Btree.Extract vs the Select but it appears that it also processes updates the indexes and creates a lock on the index file prior to extracting the keys. An ideas as to why a user would freeze and retain a lock on an index file?

Thanks, Sandra D'Angelo

Do all users have UNIQUE station id's, including the Citrix box? Unless you do something about it, you need to ensure that OI users aren't sharing the same @STATION. Sometimes, a slow connection does not release locks fast enough and the queue can get stuck.

Don M.

It's the T1 line computers that are freezing. Although, the Citrix users do have unique station id. The connection speed of the T1 line computers looks fine. The users are running a SELECT FILENAME WITH INDEXCOL CONTAINING "SEARCH STRING" frequently throughout the day. The INDEXCOL is an indexed symbolic dictionary. I know that symbolic indexes don't get updated properly if a transaction isn't created when a change occurs but could they cause a freeze? I watched the NLM_STATS and can see that occasionally, that the users get and release locks on the INDEXCOL*ROOT row of the !FILENAME. Occasionally, the lock is not released and I see the user's lock and the Indexers lock on the row simultaneously. Everyone who is running the select statement then freezes until we knock off the user with the spurious lock. Thanks for the help. Sandra

Sandra,

I know ARev had a setting to update indexes before a select, but I'm not sure of OI has a similar setting. If it does, have you tried making sure this is turned off?

[email protected]

Greyhound Lines, Inc.

Sandra,

I have been watching this thread. I am very interested in the answer to your problem. I really don't know the answer for you. I do know that there is a setting for your indexes to "update before query", as Matt was saying. And as Matt said you might want to "uncheck" it.

You can find it this way…

1) Application Manager, click the "tools" menu item.

2) Click on "database manager".

3) In database manager click the "database" menu item.

4) Click on "environment settings".

5) In the environment management window that comes up, click the button "indexes".

6) In the evnironment index settings window, uncheck the "update before query" checkbox.

I am not sure if you have to exit the appliation, or if all have to exit the application. I am not sure if this setting is for all users or just a single user.

I would assume that there is an update going on when your select is executed. That would justify index record locking (I guess).

I checked this setting and it was not enabled at this client's site. I did not think to check to see if the setting was per user. However, the client has 2 user developer and unlimited runtime license. The users that are freezing are accessing the system using the runtime license vs I checked using the developer license. How would you check this setting in the runtime directory?

Sandra,

Unfortunately, I have no more ideas for you. There are so many others that say the indexing works great for them. My experience with indexing was not so good. Too many problems, Too many weird things happening. I just resolved to creating my own indexing system.

I would suggest calling Revelation with your problem, or wait for someone else to suggest a fix.

View this thread on the forum...