Running OI7.2x, Database Manager.
I was trying to ADD a Btree Index, but when I clicked the dropdown to select the File, nothing shows. I just checked and when trying to ADD any type of Index, the dropdown is NULL. When trying to REMOVE or UPDATE Index, Files display properly.
Possibly related to this when I click OpenInsight Tables, nothing happens; nothing displays.
Any Clues/Help/suggestions would be appreciated. Thanks,
Ray Chan
If the system was migrated from ARev make sure there are no QUICK/RIGHTDEXes on the dictionaries when you add the indexes.
It could be a corrupt DBT file too. Back up the appname.DBT file and copy a clean version of SYSPROG.DBT over it and reattach all your files.
You could try running SCAN_REP, resynching the database, and rebuilding the system indexes also.
Hi Warren
1) This app wasn't migrated from AREV. As is, when you go to the DATABASE Manager, you can not add an INDEX to ANY TABLE because available tables do not display.
2) I've tried the DBT thing and also copied over a clean version of Sysprog.DBT
Anyone know where system get the list of available for ADDing Indexes? And also where it gets the list of table to show what is attached. Sofar the app is functioning, but I stumbled on this when trying to ADD an index.
Thanks,
Ray Chan
If there is a GFE in any index table the system will report back no tables. Try doing a list_index from the system monitor.
World leaders in all things RevSoft
Mr Sprezz,
I saw your earlier post and did the List_Index and all was okay, i.e., it listed tables with indexes.
Any other suggestions? Do you know why the list of Attach Tables is blank. They are probably related.
Happy New Years,
Ray
Ray,
At this point I recommend removing the index table manually (and making sure you clean up the DBT, Dictionary, and Media Map) and then attempt to create new indexes from scratch.
Hey Don,
Thanks for the response.
I manually removed the index in the table, clean up the Media Map, reset the DBT, but when I go to ADD the Btree nothing displays in the dropdown to allow me to add the index.
Never seen something like this before. Any other suggestions, anyone?
Thanks,
Ray
Ray,
Did you clean up the dictionary fields as well as remove %FIELDS% and %PROTECT.SPEC%? Did you physically delete the original index table (both the REVMEDIA pointer and the corresponding OS files)?
There's a white paper in the OI Knowledge Base Section on how to remove all the flags and other bits and pieces of indexing. It's written for version 3.7 but is still valid.
To all,
I'm still unable to add an index to an existing system. FYI, I have removed the SI.MFS info from the relevant record in Revmedia, Manually removed all indexing indicator from the Dictionaries items, Deleted the !file, Deleted the %Protect.Spec% and %Fields%. I have no problems in running List_Index from the System Monitor, but yet when I try to add a Btree index, I see the following:
The client server is running UDLite and crashed New Years and have replaced their server. I'm trying to just fix one index so they can work. If other indexes are out of whack (causing this problem), is there a structure way to find them. As is, things look ok except for the problem with the one file, but I'm stuck.
Any other thoughts would be appreciate. I have tried the above multiple times and some other stuff. NO Luck.
Thanks,
Ray Chan
Ray,
Until, a reason is determined , a workaround would be to create the index programmatically using CREATE_INDEX().
Sean
Hi Sean,
Thanks for your response.
That was my next move. However, I would really like to know what the heck is going on since in all my years (Arev and OI), I have never seen such a thing where we couldn't use standard tools to Add an Index.
Any comments/insights would be welcome.
Meanwhile, we'll do this programmatically (assuming no other issues). We're snowed under right now, but will try to get to this ASAP.
Thanks again to you and my other fellow developers who responded.
BTW, Happy New Year. Let's hope for a prosperous one,
Ray
The only time I've seen this happen in OI is when there is a QUICK/RIGHTDEX on the dictionary of the datafile.
ARev usually it was a matter of the !file not being created or there was some error in the dictionary, datafile or !file so the !file would not attach.
Hi Warren,
There are no QUICK/RIGHTDEX on the table.
For whatever reason, now that I have completely removed ALL indexes and have "programmatically" added the Btree back, the Btree Indexes arn't working AT All (????). They arn't being recognized, e.g., do a Btree search and nothing is returned, but they are shown as Indexed fields.
What corruption could cause this? I'm thinking about recreating the Table and copying data to it and see if that will help. Do you (or anyone) think that this might help or any other suggestions?
Thanks,
Ray Chan
Did you delete the sysreposix records before you did a rebuild system index.
delete_row SYSREPOSIX *
I'd generate an LH log file and see if any error popups up. If you just quickly go to the add index then shut down OI, you should be able trace it from the bottom up. Most likely there's some file mismatch somewhere, on a volume name I'd guess, and an @FILE.ERROR is getting set, which is stopping the system process.
World leaders in all things RevSoft
Mr Sprezz,
The client site is running UDLite so I created a LH3SRVC.LOG (per doc).
I put in the folder where the LH3lite.exe is. Restarted the services and did as advised. Nothing shows.
Is it possible that UDLite doesn't support the Log.
Thanks for responding,
Ray
Ray,
The log file should be placed in the oinsight.exe directory.
Sean
To all,
Thanks for all your comments.
The problem was solved with some awesome detective work by Mr Sprezz. I can honestly say that they possess the highest level of technical competence and worked hard and fast.
It's really not possible for me to explain all that was done. However, I do believe that Mr Sprezz may discuss this incident in a future blog entry. For those who have been following this thread you may want to read it when/if it appears and you may gain something. I know that I did. I didn't realize that OI can tell you so much.
Thanks again to all my fellow developers who responded. I appreciate it so much. It means a lot to me. It's lonely out here. And of course thanks to Mr. Sprezz for jumping in and making a most generous commitment to help and support the OI community. They really are Experts in All things RevSoft.
Ray Chan
Ray
Many thanks for your kind words. Without the community there'd be no Sprezz so it's a symbiotic thing :). We were pleased to be able to help.
For those of you interested in the details we've blogged about the incident here.
World leaders in all things RevSoft
Well I'm glad this was resolved. Reading Sprezzes blog it was something sublime and also something simple.
I was going to suggest enabling the logs, whether the problem was universal (all applications vs just the one), replicating the system to a local hard drive and if the problem was replicated, and how the server was rebuilt.
Having migrated an ARev and OI system from Novell to Windows SBS 2008 Server last year the importance of replicating paths is all to familiar to me. The toughest bugaboo was finding workarounds for the way Novell could root map a folder yet still access folders above the virtual root.