We have moved Arev version 3.12 over to a universal driver running

on a microsoft 2003 server. I thought that with the universal driver

locking issues where a thing of the past. I am still getting errors

on my indexing machine that says somebody has a lock on a table.

Unfortunately I no longer have the NLM_STATS to tell me who it is.

I thought the server was doing all this now. Is something not setup

properly. Is there a different means of finding out who has it locked

instead of having everyone get out of Arev?

This is not what the UD is designed to do no. At the moment there is no equivalent of the OI List_User_Locks window for AREV. It sounds as though you EITHER don't have a dedicated indexer set up OR workstations are still doing background indexing OR you have update indexes before query set (or a combination of the above).

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

At the moment there is no equivalent of the OI List_User_Locks window for AREV.

**

Does this statement imply that there will be such an equivalent in the future?

We use the NLM_STATS and LH_Statistics that the IPX LH drive provides to not only answer the whohasthelock question, but also just monitor our users and servers generally. Losing this functionality is what prevents any thoughts of a UD upgrade.

Well one could be written… whether Rev have any plans…

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Well our indexing is a process which runs on the arev server with the reporting machine and different tasks that popup and run at various times throughtout the day. By dedicated indexing machine

are we speaking about a separate computer that only has the indexing

process running on it?

How do I check to see if workstations are doing background indexing?

I don't understand the statement "indexes before query set"?

EF] How do I check to see if workstations are doing background indexing?

in Environment/Indexes menu you should find a 'Delay before indexing'. Set this to 0

EF] I don't understand the statement "indexes before query set"?

i think in the Environment/Indexes menu there is an option 'Update indexes before filter'

I went into Arev pressed F10 - Utilities - Configure - Environment- Indexes and this is what I have:

Index Managment Environment

Background Process Code Command

Replace Background

Post Index Check

Update Indexes before filter Yes

Words not indexed (list of words)

I don't have a Delay. Is this the correct spot? Is there another

place? I tried the sysprog program and the only change to this is the Background Process has a Code of S with the Command: Ck.locks.

There are a variety of .ini files that are used will I need to change

each one?

Ellen,

The "Delay Before Indexing" setting is under Configuration -] Hardware - Workstation. There is a corresponding "Time between index checks" setting as well.

These values are stored in the .INI file that is loaded. For the majority of our workstations, the Delay parameter is set to 0, which disables index processing. On our dedicated indexer, we use a custom INI file with this value set to 5.

To force the system to use an INI file other than the standard AREVC.INI (color) or AREVM.INI (monochrome), you can put a SET AREV= in the AUTOEXEC.BAT. This tells ARev to use that INI file instead.

You also might try disabling the "Update Indexes before filter" (set it to No). This tells the system to perform an Index.Flush before any query that uses an indexed field. This could be interfering with your background indexer. This is especially true if the background indexer is in the process of updating an index that a workstation is trying to flush prior to running a query.

Hope this helps.

[email protected]

Greyhound Lines, Inc.

We have set "Update indexes before filter" to Yes and I don't thing there are problems.

Only when I created an index, and tried to force its "creation" using filter, I had to wait until indexor, which detected the new index and was in the proccess, finishes its job.

I thing it saved me time as indexor starts earlier and my machine has nothing to do after it… Normally indexor performs a small number of transactions with the particular file in a batch. So you don't have to wait long time.

The question is when performing query … are you interested on current state of the databases or the last flushed state is sufficient? For normal use I thing it does not matter, but in the batch processing you need the flushed data. … So use of explicit flushing in batch processing is needed in your case. (Or run batch processing with the option set to Yes).

(Of course it is important which of worst case/amortized complexity is most important for your application.)

Have anybody problems with "Update indexes before filter" set to Yes.

Which kind of problems?

It can cause problems amongst multiple users if they are running queries against the same table, and if that table receives lots of updates.

User A starts a process that uses a query, so it starts flushing the index. User B starts another query process on the same table, but it can't proceed until the index flush started by User A has completed.

It's basically a contention issue. If there are a low number of updates, it's minimal. The higher the number of transactions, the greater a chance of contention.

However, if you have your dedicated index server checking often enough, you usually don't need to flush before query.

[email protected]

Greyhound Lines, Inc.

But what is wrong with this?

User B should wait Index flushes to end.

When A's Index Flush is finished, B's index flush takes very small time. Suppose both PC's are equaly fast, than B waits smaller time as User A started earlier. (He usually waits smaller time compared to case A not invoking index flush at all).

Am I wrong?

I have rather asked for problems with data corruption etc., not for a problem with surprised users .

I agree that for a table with frequent changes in indexed fields it can be more useful not to force index flush (especially if you are not interested in recent changes).

Because what usually happens is that User B reboots they're machine instead of waiting for User A's flush to complete.

It happens in English speaking countries?

Users :(.

Our users cannot read the message so they call another one for help and this is sufficient time for flush to finish ;)

View this thread on the forum...