I came across a problem in our 'runtime' environment, that when an RList Select xxxxx statement is executed, we get an error message saying that the index file !filename*account*volume is not available. The indexes are working for index lookups, new records are being added, I can see the indexes, update, remove, rebuild, etc.

It is just the Select statement that is having a problem. When I turned 'Update indexes before query' off in the environment, the error was eliminated - but the functionality is lost as well.

Any ideas about this? Has it happened to anyone else?

Thanks,

Jeff

Jeff,

Was there an error number or anything else with the error message? Perhaps it is related to the RDK issue with indexes that you found.

Cameron Purdy

Revelation Software

Jeff,

This happened to my OI/app today. Yesterday everything worked fine.

I use a developer OI 3.3. That is different from your case, but today I have consistently got the exact same message as you (but with different table, app and location names, obviously). All my trusty old Rlist calls (and the new ones too) now appear to fail. On closer inspection I've found that Rlist really succeeds, but afterwards Get_Status believes there is an error. @FILE_ERROR, on the other hand, is null and so in total disagreement with Get_Status. I have tried to rebuild system indexes etc, but nothing seems to help. (I haven't tried to turn off 'Update indexes before query' yet, though).

I have tried to think if there was something special I did between yesterday and today. The only thing that comes to my mind is that I exchanged the data location for a different one - one with the same tables but with different data. But I think I did it the proper way: I started OI and removed all the tables. I then closed OI and moved all the files out of the location's folder, and replaced them with the contents of the other location's folder. Finally I started OI and added all the tables again. I have done this many times lately because I do experiments on two different data sets, from two of our clients.

But just in case there is now something wrong with my location, and not OI itself, I will try to change back to the old location. Wait a minute…

… … …

…and big surprise! Now the error is not

  "FS210" : @VM : "!**"

but

  "invalid word before Table Name"!!!

Help!!!!!!!!

- Oystein -

Øystein Reigem,

Humanistisk datasenter

(Norwegian Computing Centre for the Humanities),

Harald Haarfagresgt 31,

N-5007 Bergen,

Norway

Tel: +47 55 58 32 42

Fax: +47 55 58 94 70

E-mail: oystein.reigem@hd.uib.no

Jeff,

When I got "invalid word before Table Name" with the other location that was just because I hadn't added properly.

After correcting that I found that Rlist/Get_Status worked fine with the other location.

So I have one "bad" location that has the problem and one "good" location that works fine.

Can the following be a clue: I seem to get the RIX101 message when I save the database after removing the "good" location. When I get the RIX message I follow a piece of advice from this discussion list: I remove the system index with

  run DELETE_ROW "SYSREPOSIX", "*"

and rebuild it the normal way. Rebuilding then ends with an "FS" message (just "FS" and no number), which I hope is good-natured.

- Oystein -

Øystein Reigem,

Humanistisk datasenter

(Norwegian Computing Centre for the Humanities),

Harald Haarfagresgt 31,

N-5007 Bergen,

Norway

Tel: +47 55 58 32 42

Fax: +47 55 58 94 70

E-mail: oystein.reigem@hd.uib.no

I finally resolved this problem by removing the indexes from the file completely and rebuilding them - making sure the !filename is deleted as well.

Just rebuilding didn't help. I should add that in my case, the fields we were selecting on both had indexes on them.

Since rebuilding, we haven't had any more problems with indexes - and we've actually got an application deployed.

Hope this helps,

Jeff

Jeff,

I finally resolved this problem by removing the indexes from the file completely and rebuilding them - making sure the !filename is deleted as well.

Thank you very much!

So the theory is:

1. There was something wrong with the indexes.

2. 'Update indexes before query' being set, Rlist triggered an index update, which perhaps discovered that something was wrong, or perhaps just left something in a different state than usual.

3. Get_Status discovered that something was wrong.

4. But it was something unusual because @FILE_ERROR didn't.

With a different dataset I'd probably tried making the indexes anew myself already, but this dataset is so large, and there are so many indexes, it takes a whole day! And nothing else has indicated a problem with the indexes.

And there is another thing that has kept me from it. When I have problems with indexes it's always been with one table at a time. This time it's with at least 3 of the 6 tables in the location. (I haven't checked the other 3.)

This makes me think something special caused the problem. I'd really like to know what!!!!

And I'd like to know where that error status came from, and if it was bogus or not, I mean with Get_Status and "FILE_ERROR disagreeing.

- Oystein -

Cameron,

At least I don't use the RDK. I'd be thankful if you had a look at the "Thanks for the remedy, but the mystery remains" posting in this thread and see if you get any ideas about the cause.

- Oystein -

I decided to do some more tests before I reindexed the location (or I think I'll rather throw it in the bin soon!!!).

Some unindexed searches fail too

I now also tried to search on an unindexed field. This time Get_Status got

"FS1003" : @VM :

"REGIMUS\BRUKDATA\REV43145.LK" : @VM :

15649 : @VM

The REV43145 mentioned in the status text is one of the problematic tables, i.e, a data table, not an index table. It's the main table of the app and it's big - the LK file is 16,131K and OV is 11,391K.

When I tried to search on an unindexed field in a different problematic table, everything went fine.

Different when run from Exec line

I then tried to run the same searches (some indexed, and the unindexed one above) from the Exec line instead of from a user event. For the indexed fields I got the same FS210 thing, but for the unindexed field the search succeeded. So here is another case of disagreement.

LH Verify problems

Finally I ran LH Verify on the problematic tables and their indexes. All index tables were fine. The data tables seemed to be fine too because LH Verify didn't report any problems. But in fact it reported nothing at all! It should have said "No Group Format errors", but the "Errors" box was just empty when it finished! And another thing: Verifying the aforementioned main table seemed to mess up the system so that LH Verify after that reported "Group Format Errors" on every table I checked, even on other locations! I had to close and re-start OI to get it reset to normal. This happened just with that main data table, not with the other data tables.

- Oystein -

Oystein,

… I mean with Get_Status and "FILE_ERROR disagreeing.

@file.error and Get_Status have little to do with each other. If they are equal, then that is only a coincidence.

Every file operation (open, read, write, etc.) is responsible for setting up @file.error. If a program wants to report that information to its caller, it calls Set_FSError() which transfers the information from @file.error using the Set_Status() function which then allows the caller to use Get_Status() to retrieve the error information.

Cameron Purdy

info@revelation.com

And there is another thing that has kept me from it. When I have problems with indexes it's always been with one table at a time. This time it's with at least 3 of the 6 tables in the location. (I haven't checked the other 3.)

You mentioned moving the files around - I think that 'may' have something to do with it. In our case - I believe I had just deployed the application, and I had attached the production files to the development system and built (rebuilt?) the indexes for the files. Everything in the windows worked fine, index lookups, updates, etc. - it was just the R/List that was causing the problem.

I don't know the answer at this point. It would seem that by comparing the way R/List (or more specifically update indexes before a query) looks at/checks index files and the way IXLOOKUP gathers index information - we may get a clue as to what's going wrong. What is the difference in the way these process find/report on index status?

I'm also wondering if there is 'anywhere' in the system that actual DOS filenames are stored besides the REVMEDIA files?

Jeff

You've got this going under too many names and too many threads and I'm really confused where you are with this.

What are the status errors comming back?

What is returned by get_status?

What is returned by @file.error?

Sometimes these items get set by benign processes and you are not looking close enough. For example, @FILE.ERROR returns back and error when ReadNext is finished it's process. It could be following down a node tree to do an update, finding the next record does not exist, and returning back an error. However, these errors are not really errors.

apk@sprezzatura.com

Sprezzatura, Inc.

Aaron,

You've got this going under too many names and too many threads and I'm really confused where you are with this.

Are you sure?

Well, seriously - I have had two different problems lately where I tried to use Get_Status and stuff to find out what went wrong. One was with aliasing tables. You replied to that and if you could help me further I would be very grateful.

The other one was with RList. I'll stick to that here. But perhaps you should consult my other late posting in this thread too.

What are the status errors comming back?

It depends.

1. Search on an indexed field:

What is returned by get_status?

  "FS210" : @VM : "!OBJEKT*REGIMUS*AAAAA"

i.e,

  "!""*""*".

What is returned by @file.error?

  "111"

2. Search on an unindexed field:

What is returned by get_status?

  "FS1003" : @VM :

  "REGIMUS\BRUKDATA\REV43145.LK" : @VM :

  15649 : @VM

The REV43145 table is a data table. It's big - 16+11K.

What is returned by @file.error?

  "400" : @FM

(And before RList is run it's "100! : @FM : "SYSPROG*LOSTFOCUS".)

- Oystein -

View this thread on the forum...