Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 20 NOV 2000 10:45:36PM Scott, LMS wrote:

Hi All

Another execise in frustration:

Arev 3.12, Novell Lan, NLM IPX 1.5 23 users (strange but the OI NLM on this site is unlimited users)

The index tables (but nothing else) seem to be all broken (or lots and lots of them).

We had an indexing machine running. We've had the system up and going with the indexing machine for a week now. Today we start getting errors like:

fatal error reading *INDEXES in table !AH_AIR_CON

FS 493

Group Format Error

OS File ..\DATA\FIN\REV25448.LK

GROUP # 0

The Group Contains an invalid frame type value

ESC to terminate…

I tried

VERIFYLH ..\DATA\FIN !AH_AIR_CON (FD)

got

*group format errors found, use the fixLH utility to fix this table

I tried

FIXLH !AH_AIR_CON

got nothing

so I tried

VERIFYLH ..\DATA\FIN !AH_AIR_CON

got

MYAPP*!AH_AIR_CON group 0 code 3

Initial setup failed Primary Frame header type is incorrect

If I try

VERIFYLH ..\DATA\FIN AH_AIR_CON

I get

Table AH_AIR_CON is not available for verifying

If I try to list AH_AIR_CON

I get the first error.

I can still list the indexes assigned by doing

LI AH_AIR_CON

but when I try to rebuild the indexes I now get a message saying there are no indexes on this table. Huh?

This is happening with most of our Index files.

My only theory on what happened is that some how the indexing machine process was allowed to continue when they took the directories off line for some reason. I am unable to contact any of the network people at this point to confirm this.

All I really want is to make it go away. My current tedious thought on this is to copy all the dos files corresponding to the index files back and rebuild the indexes. Ugly.

Help Please

Scott, LMS


At 21 NOV 2000 01:39AM Scott, LMS wrote:

Hi All

Well I got the dos copy of the index from a backup copy of the app and replaced the dodgy index dos files with the backup ones.

Then I did a verify on the new (restored from backup) index file. No GPF errors. And then I rebuilt the indexes. Now I can list that file. It seems ok.

The ones that are broken are pretty easy to spot as Dos Files now, the file size has become something really silly like 4 Gig.

Anyway when I tried to do AREV Lanpack on this system I got

"The linear hash Client/Server TSR is not installed, linear hash software will not be used. Use only local files or log out and check your workstation config".

If only I knew how to make that go away, like I check my workstation config but what am I looking for and what do I change it too. Incidentally I don't know how to get the thing to start up in dev mode either. I know for OI but not AREV. Do you have to overwrite arev.exe, if so with what. Do you have to use /dv=1 on the shortcut or bat file, could someone reply with an example please.

The other thing that bothers me is the NLM/Lanpack that we have for this client's AREV thinks it is limited to 23 users but the OI one is unlimited. If I try to change the users on AREV it asks for an install disk - which I don't have. Do I need to sort this problem out or is it irelevant? We don't need more than 23 users for the arev. We do need it to work properly.

We have been having intermittant problems - that I hoped would go away with something along the lines of

error connecting to… RTP57

This only happens sometimes, and it only happens to some people and usually when they've been switching between different programs eg word, arev, excel etc.

Scott


At 22 NOV 2000 08:46AM Don Miller C3 Inc. wrote:

The NLM doesn't care how many users only AREV.EXE and OINSIGHT.EXE, actually OENGINE.EXE care. Have you checked the client desktops for write-behind caching turned on? I've seen similar file problems (despite the NLM or NT service) if it's turned on (particularly in Win 95/98).

Don Miller

C3 Inc.


At 22 NOV 2000 06:36PM Scott, LMS wrote:

Hi Don

What is write behind caching and how do I turn it off. I found the bit on the short cut where I can turn the screen saver off but not the caching.

The search system has been broken so this problem is killing me.

Scott, LMS


At 22 NOV 2000 07:36PM Donald Bakke wrote:

Janet,

Write-behind caching is turned off by doing the following:

1. Right-click on the My Computer icon and select Properties

2. Select the Performance tab

3. Click on the File System button

4. Select the Troubleshooting tab

5. Click on the Disable write-behind caching for all drives checkbox

[email protected]

SRP Computer Solutions, Inc.


At 23 NOV 2000 08:31PM Scott, LMS wrote:

Hi Donald

Thanks for that. The search, when it came back to life was fairly helpful. I don't know why I hadn't heard about it before. None of our clients PCs had write behind caching turned off.

The thing about the TSR/Linear Hash server seems to have gone away by itself.

"Restoring" the dos files for the indexes and rebuilding them worked for all but one file. I discovered that this particular file has been broken a very long time. I was able to remove the indexes (two relational indexes) on our dev system but not on the live system.

I couldn't edit the systables record for the file to remove the index that way either (read only file!?). I now need to learn more about the arev dev system. Our stuff is so layered over the top I am having trouble finding it. Why does this make me feel like a paleantologist (dinosaur scientist)?

All up, our client is using the system again, declared it working but I don't really know why it broke or why it's "fixed" now.

Scott, LMS


At 24 NOV 2000 10:58AM Donald Bakke wrote:

Janet,

I couldn't edit the systables record for the file to remove the index that way either (read only file!?).

SYSTABLES is a table that is created in RAM by the system upon logging into AREV. That is why it is Read-Only and will not allow you to modify it directly.

[email protected]

SRP Computer Solutions, Inc.

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/695a009c05c3bf628525699e0014a7b3.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1