OI 4.1.3 Dictionaries from ARev 3.12 (cleaned up to be OI compliant).

All indexing was removed using index tools in ARev 3.12 and double checked manually as per KB article "Removing Indexes Manullay in OpenInsight 3.7".

When attempting to add a BTREE index via Database Manager after I commit the add button and error pops up "FS210 Index for "!table*global*media label" is not available." No !file is created. Checking the dictionary item shows the appropriate flag set in field 6.

Doing the same in DM_MAIN gives error "Unknown Error !file*global*media label" 2". Again, no !file created but dictionary items get updated.

All the ARev files are on account/application global.

I created a new table in ARev, set account/application to global, built 3 dictionary items, logged out of ARev, logged in via OI. I was able to add indexes with no problems (empty file).

I created a new table via Database Manager in OI. Indexes added with no problem.

I was able to add indexing to an existing table, but consistently fails on the tables I need indexing on.

Using the List Index function in DM shows no indexes.

Using the List Index function in DM_MAIN shows the indexes.

Workstation is Win2K Pro, Novell Netware 3.x (not using NLM for conversion test although the live system uses NLM). Novell client 32 is being used on workstation (v4.83sp2).

What's going on?

Have you disabled write-behind caching and enabled true commit in the Netware client?

Ok, there's no write-behind caching property but I turn off file caching and turned on true commit in the Netware client, restarted and still get the same problem.

The application is dead in the water without indexes.

What now?

Warren,

Steve seems to think the problems have something to do with networking. He might have good reasons. Myself I don't know. I'm a dummy when it comes to multi-user and network stuff. But what happens if you move your system to a local computer?

Say it's got nothing to do with networking. In my experience that FS210 index for !table message you're getting is typical for an inconsistent system. The error message shows a volume label. Check your dbt file to see if the relevant entry there has the same label. Check REVMEDIA to see if it contains the right entries. Check to see if dictionaries and indexes agree on which indexes are present. And of course try to remove and add your tables with Database Manager. (Some of my suggestions here might be off target, but some are relevant.)

- Oystein -

Could the DBT file still have the !file or SI.MFS on it?

The Sprezzatura Group

World Leaders in all things RevSoft

Anything is possible.

Is there any documentation on the structure of the DBT file. I can suss it out but don't want to make too many assumptions.

Yeah, something is hosed somewhere. I don't know enough about the internals of OI to figure it out.

I removed all the datatables from the DM and saved. I then added only one datafile that I want to index. When I saved the database changes I saw it flash that it was removing a bunch of tables, one of them was a !file (that I could see) and it is one of the problem children.

I guess what's going on is akin to the quickattach problems that crop up in ARev now and then.

Warren-

What may be happening is that when you remove indexes from DM, you should log out of OI and then back in before you add indexes again.

The information is cached in the DBT file, so if you remove and then add withoug logging out it is only 'half' put back on.

Warren,

If you suspect your DBT file is hosed you can "start from scratch" by replacing your appname.DBT file with a SYSPROG.DBT (renamed of course). This will remove all local application table references. You will need to add them back again but at least it will give you a fresh start.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

I tried that. I've also tried running it locally. Same thing. I tried removing all the indexes on the volume and renaming the media/volume thinking perhaps the double space between time and date was throwing it off. No dice.

I'll try Don's suggestion and start with a fresh DBT file.

At least after I removed all the files the listindex function starting working again.

The bang file is not getting created in any case.

Warren,

I've never needed docs when doing this. Just open the file with a text editor or as a text file with Word. (But don't change and save it again.) I think you will recognize what you need to see.

- Oystein -

Just open the file with a text editor or as a text file with Word.

Egads! If you have AREV then use that instead. Reads much better and you can Ctrl-E to zoom into the dynamic arrays.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Well starting over with the SYSPROG.DBT did not help.

I'm considering reinstalling OI and starting over. What would be the best way to backup all the procedures and stuff I've made while dumping the datafiles? Does an APPBACKUP exclude datafiles and associated DBTABLE entries in the SYSREPOS?

Warren,

Did you try to remove and add the datatables themselves? I'm not talking about the indexes. Do File|Remove and File|Add in Database Manager.

Did you have a look in REVMEDIA to see if there are unwanted entries there? I think I once that same kind of FS210 message that you got - one that talks about an index for an index - and when I looked in REVMEDIA there was a !table entry there for a non-existent table (or for a non-existent index table - I don't remember).

- Oystein -

The AppBackup will backup the repository of ALL entities for that application. There is a check box which allows you to EXCLUDE any data tables.

It is prudent proceedure to do Appbackups periodicly, thus if the system catches a cold you can quickly install the app into a replacement system. Then just re-attach data tables.

Richard Bright

Thanks to Bill & Mike we were able to resolve this problem.

The culprit - QUICKDEX on the Dictionaries.

Looks like the QUICK/RIGHTDEX.MFS somehow interferes the writes to the !file.

Something to add to the ARev to OI conversion notes: Remove QUICK/RIGHTDEX from dictionaries (or resolve in 7.0).

View this thread on the Works forum...