Indexes not working OI 9.1 (OpenInsight 32-Bit)
At 13 OCT 2009 06:51:43PM Paxton Scott wrote:
Greetings!
Strange thing happened today. I have a machine that runs Apache2 and OI 9.1 and uses oecgi2.
This is our test machine and does not have UD4.5 on it.
The OI is normally only accessed from the browser and we do searches.
In our case, we made a bad choice of delimiters, so we wanted to rebuild the crossreference indexes with 14 specific delimiters . , ( ) ; : and space - _ { } and our own list of 5 stop words.
I removed the cross reference indexes, and installed them again with our delimiters and stop list.
No searches worked.
So, I took all the indexes off, checked the ! file was gone and the MFS was gone
Installed the btree and crossref indexes again, still no keys returned from the btree statement. Since oecgi2, can't use debugger, so i use OSWrite to write out the search string and the keys returned.
Search string looks good (ought to, nothing changed) but no keys returned
Ran LHVERIFY on all the files in the volume - No GFE's.
Checked the !file in the editor; about 30K records, the *INDEX record shows all the indexes
In TCL, I do a list statements, and seems like indexes might be working, pretty fast, but I do not know how to tell for sure that LIST is using the indexes.
This is something that has been running for 5 years or so.
We have removed and added indexes in the past no problem
recently upgraded to 9.1, first index change since then.
I wonder if could be something with 9.1?
Any ideas what I might be missing?
Have fun,
Paxton
At 14 OCT 2009 09:02AM Jared Bratu wrote:
This posting doesn't directly answer your index question but I wanted to bring up two points to consider regarding the setup and debugging.
First, thank you for mentioning this machine doesn't have the UD installed. I trust that your production system does. Even though OECGI2 is local to the database files on the server there is still a need to run the Universal Driver. The setup is similar to having multiple local users each accessing the linear hash files directly. Since there is no network between the application and the database files the chances of a GFE are greatly reduced but in the end each application (oecgi2/oengine) is still accessing the files directly which opens up other problems. Without the UD the applications (oecgi2/oengine) can't efficiently coordinate their access to the database files.
Second, OECGI2 can use the debugger. Did you see the article Bob Carten wrote? http://docs.google.com/Doc?id=dhh9ztnx_55k9w39rhf
At 14 OCT 2009 10:58AM Paxton Scott wrote:
Thanks, Jared.
Yes we have ud4.5 running on production, and the 4.6 upgrade is here, but not yet installed.
I am aware of Bob's article on ways to debug in oecgi2
When we reinstalled the indexes with the default settings it works again
we are investigating further, seems there is something about the custom stop list that is causing a problem.
Have fun,
Paxton