Customer is running:

AREV 3.12 application

That went well didn't it - I'll try again!

Customer is running:

 . AREV v3.12 application (46 user)

 . OI v8.07 application (250 user)

 . UD 4.5 driver

 . Linear Hash Service

Suddenly, they have been experiencing hundred's, if not thousands of critical Linear Hash events in the server Application event log.

These are mostly errors 126 and 127.

I know the table these relate to. It's a table with 340,000 records, in 160Mb.

If I do a verify from OI Database Manager, the table reports no errors.

If I do a verify from AREV, I get about 40 errors, all Code 10, Overflow frame x, boundary y; forward pointer points to a nonexistent position.

While the "Overflow frame x" is different in each case, the "boundary y" is the same y each time.

I have been using AREV, dumplh, ctrl-F and fixing each group.

Once I have done this, the critical events stop occuring - until next time!

I have no idea what's causing the problem - it suddenly started on 23 DEC 08.

If the Linear Hash service is stopped and started around the backup process, could that be a problem if users haven't logged off, and perhaps a workstation is updating indexes?

That's about all I can think of.

If so, how should we handle that, given that users are in several locations across Australia?

At the moment, I fix them, and then they come back again.

Thanks.

Mathew Jones.

ARev dumplh and verifylh routines do not recognize the header changes from using the UD as I recall. Use the OI versions only.

Thanks Warren.

The problem with that suggestion is that OI is reporting NO errors, AREV IS reporting errors, and the Linear Hash service is generating thousands of critical event errors.

So, while OI is not reporting gfe's with its function, the linear hash service is reporting errors.

If I only use the OI version as you suggest, I will be suggesting to the client that there are no errors on his table(s), yet his event log is filling with thousands of critical error entries!!??

If AREV doesn't recognise the header changes, presumably I shouldn't be using the AREV verifylh and dumplh routines.

How then should I fix the table(s), and get to a position where the linear hash service is not logging errors, given that OI is not even reporting errors??

OI has nothing to fix, yet there are thousand of event log entries!

Suggestions please!?

Thanks.

Matthew Jones.

Warren is right, the AREV tools do not understand the new frame sizes and you should not be using them to fix errors. Your observation about the errors no longer occurring is intriguing.

1)Run a verify from OI locally on the server? Please turn the Linear Hash service off and verify no one is able to start OpenInsight before starting the verify. What are the results? Did any errors get posted to the event log?

2)Try a utility like OpenedFilesView http://www.nirsoft.net/utils/opened_files_view.html to check if any applications (virus scanners, backup programs, local users) are opening the .lk and .ov files directly when the event log error appear. Run the utility on the server, under normal circumstances the only process opening these files should be lh45srvc.exe

3)Can you correlate the event log errors to either OpenInsight and or AREV? Try using only the OpenInsight version for a while and see what is posted to the event log, then try the AREV version. Any correlation?

Thanks for the information and suggestions Jared.

It's hard to get a run at their server with no-one else on the system.

Hopefully I can try this tonight (21 JAN, Aust WDST)!

I will report back what I find.

Cheers,

Matthew Jones.

You can use Jared's suggestion about watching file activity with users logged in. You should only see activity against REV files by the LH4SRVC used by the SYSTEM user. It sounds very likely that it's our old friend MacAfee or similar. www.sysinternals.com also has some cool tools for this kind of thing.

The Sprezzatura Group

World leaders in all things RevSoft

I had trouble closing the Linear Hash service - had to end task in the end!

After closing and re-starting, did a verify in OI on all volumes and found nothing!

Have installed the OpenedFilesView utility.

Will monitor tomorrow during use, if any critical events happen.

Cannot switch off either AREV or OI to determine which may be the cause - AREV is used by all users; OI runs a server module required by everyone!

Mathew,

I had a problem with the UD3 on a Novel server. Although the environment is different the cause may be related to your setup. We had both AREV and OI accessing the data and periodically the SYSTEMP file in OI kept getting corrupt. After much investigation it was found that some OI users were bypassing the UD and accessing the files locally. As it turns out, the UD3 has a feature where you can put an umbrella revparam file to cover an entire folder/subfolders. So we put a revparam in the Revsoft folder. This should have covered all folders under it including OInsight. The problem is that some users did not have network access to read the revsoft folder only the folder under it. As a result, they could load OpenInsight but it reverted to opening the files without use of the UD. Thankfully, our data folders were located elsewhere and each had its own revparam file.

Not sure this will help but keep in mind the revparams are important. Sometimes more important than you realize as there was no outward indication other than corrupt files…

John

Thanks for that John.

There are two folder structures:

 . one folder contains AREV.EXE and has sub-folders, inc data

 . the other folder contains OINSIGHT.EXE and has sub-folders, inc data

Both top-level folders with the exe's contain REVPARAM files.

Each REVPARAM file contains:

 . ServerOnly=1

 . ServerName=192.168.0.10

 . TcpIpPort=777

These are the only REVPARAM files within these folder structures.

Is that ok?

Cheers.

It should be ok as the UD uses the revparam at the top level and applies it to all subfolders. Of course someone from Revelation should comment…

My problem stemmed from the fact that the revparam was in a parent folder which was inaccessible to some users. In the end we ended up putting a revparam in each folder containing rev data files just to be safe.

John

It's sorted - brief summary:

There are multiple data sets, each is a folder with sub-folders.

There are 'beta' folders that are copies of live data, for users to familiarise themselves with the oi version of our software.

The beta data update process runs each night so data is 'live', but only copies changed files.

An index table related to a static historical table was corrupted in the beta data somtime in December 08 (when the errors started).

Whenever a user accessed the beta data, and an index update executed, as it scanned the tables it filled the event log with critical read errors trying to access that corrupt file.

The beta update process has been changed to copy all files, and now the problem is gone!!

Questions arising:

 1. is it possible to retain indexes on a historical, static table, but have the system not check for index updates on those tables, as the data is not changing? Presumably that would speed up the index update process, as it would bypass those tables.

 2. is it possible for the Linear Hash service to provide [b]some[/b] information about the errors it encounters? All it provided in this case was the error number, group number, and a truncated record id. It would have saved a whole lot of time if the event log contained an os file name, including folder, as it does in the Universal Driver manager, when viewing locks? As I had nothing to go on, I spent a lot of time looking in the wrong OI table, and in the wrong folder!

Thanks for the help on this.

A little late on #1, but depending on the number of files, the time taken to check for index updates should be negligible that it really doesn't matter. If you really want these not to be updated, then don't have them attached in your indexer.

View this thread on the Works forum...