Can't Add Index, Don't see Tables (OpenInsight 32-bit Specific)
At 07 JAN 2011 02:07:48PM Ray Chan wrote:
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
At 07 JAN 2011 03:54PM Warren Auyong wrote:
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.
At 07 JAN 2011 04:11PM Ray Chan wrote:
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
At 07 JAN 2011 04:33PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
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
At 07 JAN 2011 04:54PM Ray Chan wrote:
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
At 07 JAN 2011 05:37PM dbakke@srpcs.com's Don Bakke wrote:
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.
dbakke@srpcs.com
At 07 JAN 2011 05:55PM Ray Chan wrote:
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
At 07 JAN 2011 09:48PM dbakke@srpcs.com's Don Bakke wrote:
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)?
dbakke@srpcs.com
At 08 JAN 2011 12:03AM Warren Auyong wrote:
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.
At 09 JAN 2011 05:02PM Ray Chan wrote:
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
At 10 JAN 2011 09:37AM Sean FitzSimons wrote:
Ray,
Until, a reason is determined , a workaround would be to create the index programmatically using CREATE_INDEX().
Sean
At 10 JAN 2011 09:53AM Ray Chan wrote:
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
At 10 JAN 2011 10:50AM Warren Auyong wrote:
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.
At 10 JAN 2011 02:13PM Ray Chan wrote:
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
At 10 JAN 2011 04:56PM Barry Stevens wrote:
Did you delete the sysreposix records before you did a rebuild system index.
delete_row SYSREPOSIX *
At 11 JAN 2011 08:49AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
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
At 11 JAN 2011 11:27AM Ray Chan wrote:
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
At 11 JAN 2011 11:49AM Sean FitzSimons wrote:
Ray,
The log file should be placed in the oinsight.exe directory.
Sean
At 11 JAN 2011 11:16PM Ray Chan wrote:
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
At 12 JAN 2011 11:44AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
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
At 13 JAN 2011 01:25AM Warren Auyong wrote:
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.