Hi All

I'm having one of those nightmare weeks. Has anyone else experienced anything like this, if so, what did you do about it? (warning: this post reflects a whole day of hair pulling)

My set of forms for updating records in a particular table, have decided not to update the records any more.

I can open a record up, and look at it but I can't change anything. There is no error message. I have added a new field to the table dictionary and changed one form to add a new field bound to the new part of the table. I don't see why this should mean that all the other fields and the other quite separate forms no longer work.

I did experiment with the database settings on locking ie checking the co-ordinate with table locks and ignore self locks. I discovered that the record being locked but never unlocked, but I got no error messages until I tried to edit the record in system editor. Then I got "this terminal already has this record locked" or words to that effect. I still don't understand how this could have affected my other forms. I reset the locking parameters to how they were before, and saved the form again, but the problem hasn't gone away.

In fact, I can't even add data to the record using system editor! Not even a new record. Well I can save a place holder ie the key and not get a "row not found" when I retrieve it but there is no data in the record and I can't make any I put there "stick".

I think the file is buggered in some way - there is data in it, which I can look at but I can't update it. I can update other rev files in the same directory, and there are no read only flags on the associated files. I can't edit the problem table from another computer either.

I removed all 20 indexes from the file, and rebuilt all the remaining indexes on the whole application, still no joy.

Now to mess with the dictionary some more? Nope that didn't help.

Ok I am now down to using various backups to see if I can do a restore to fix the problem or at least isolate it a bit. This means about a week's worth of work down the drain…

Problem seems lodged with the index file for some reason. Even when I thought I had removed all the indexes. And even when I had removed all the indexes I still had the dos files for the indexes. And of course the combination of current data and dictionary with backup index file doesn't work because I removed the relational index. .

Anyone know how this may have become broken (so I don't do it again), or how I might fix it now? Ie can I somehow rebuild the current index file or make it go away properly?

Scott, LMS

not happy.

keywords: problem broken table file update index relational thatchless stressfull scream ARRRGGH…

I don't know about cause, and I have never had anything quite as bizarre as this, but where I have had problems with indexes in the past I

a) ensure that SI.MFS is removed both in OI and in Revmedia.

b) Delete_Table on the bang file - and ensure gone from Revmedia

c) Define database

d) sometimes - rebuild system indexes - while I have a cuppa, go buy a wig or something …

e) Log out and back in and then re-create the index (es).

Simon

RebusHR

Scott,

Do you know about the manual procedure for removing indexes? See this Technical Article.

This article says it's for "Removing Indexes Manually in OpenInsight 3.7", but I think it's basically the same as one that's been around for a long time, and not at all special for version 3.7.

- Oystein -

Hi All

thanks for that, I will see if I can figure out Oystein's link

bang file is the !file right?

I can't believe the tv right now. Well when I can believe it I want to throw up.

Scott

Me too friend. I live 100 miles from NYC and go there quite often. Wouldn't want to be Ben-Laden at this point .. nosiree. An awful lot of folks here think his warnings came true.

Don M.

Our offices are less than 20 miles from the trade center. When some of us went to the blood bank, we could see smoke where the towers used to be.

I know of many people who work in the area, and there are a few clients within two blocks of the area. I don't know their status.

It's a cowardly act of terrorism. I send my prayers to all those who lost friends and family in the NY, Washington, and the plane crashes.

Mike

Mike ..

Well said .. well done! Thank you.

Don Miller

C3 Inc.

Hi All

The corrupt index file is now fixed and I can now update my records. In fact I could make updates as soon as all the indexes were removed. I conclude that broken index files can stop the main file from being updated.

Oystein's pointer for manually removing indexes was very handy.

I changed the bit for the cross reference indexes that said

RUN DELETE_TABLE "DICT.TABLENAME","FIELD_XREF"

to

RUN DELETE_ROW "DICT.TABLENAME","FIELD_XREF"

Actually most of the indexes were already gone because I'd tried to remove them all before, using the database manager index tool. I didn't have to reset any of the field 6's.

What was left was the relational index stuff (especially in the target file dictionaries) and the xref.

I used Oystein's relational Index report too, to report all the relational index source and target fields. I modified it a bit to write a tab delimited file so I could sort it with ms excel. I will probably modify this a bit more to list the btree and xref indexes too. The whole lot is getting printed out as a hard copy back up.

Code for listing relational indexes (Oystein)

And for completeness, the knowledge base article for trouble shooting indexes, don't forget to modify this.

How to manually remove indexes

Scott, LMS

Oops forgot an end quote. I am so dependent on good compilers and test runs.

Hi All

The corrupt index file is now fixed and I can now update my records. In fact I could make updates as soon as all the indexes were removed. I conclude that broken index files can stop the main file from being updated.

Oystein's pointer for manually removing indexes was very handy.

I changed the bit for the cross reference indexes that said

RUN DELETE_TABLE "DICT.TABLENAME","FIELD_XREF"

to

RUN DELETE_ROW "DICT.TABLENAME","FIELD_XREF"

Actually most of the indexes were already gone because I'd tried to remove them all before, using the database manager index tool. I didn't have to reset any of the field 6's.

What was left was the relational index stuff (especially in the target files) and the xref.

I used Oystein's relational Index report too, to report all the relational index source and target fields. I modified it a bit to write a tab delimited file so I could sort it with ms excel. I will probably modify this a bit more to list the btree and xref indexes too. The whole lot is getting printed out as a hard copy back up.

Code for listing relational indexes (Oystein)

And for completeness, the knowledge base article for trouble shooting indexes, don't forget to modify this.

How to manually remove indexes

Scott, LMS

View this thread on the forum...