Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Issue creating BTREE Index
I am wanting to create a BTREE index on a field. But when I try to create it. I receive a pop-up stating that I can't create a index while I have a rightdex or quickdex installed on the table.
How do I go about creating a BTREE index?
I have thought about removing rightdex and quickdex but I am afraid that I will do some damage to the data or forms already in use.
Please guide me in the right direction.
Thank you
User: Mark Mayfield
How do I go about creating a BTREE index?
I have thought about removing rightdex and quickdex but I am afraid that I will do some damage to the data or forms already in use.
Please guide me in the right direction.
Thank you
User: Mark Mayfield
Comments
That is the first I have heard of a BTREE index refusing to be created because of an existing quick/rightdex. What version of OpenInsight are you using?
In my opinion something else is going on so I would tread carefully. At least make sure you have a backup of this table just to be able to quickly recover. I am not worried that you will lose data, but the database pointer system could be messed up enough to cause OpenInsight to fail to access the table without some additional surgery.
If you are comfortable moving forward then you could attempt to remove the quick/rightdex and then add the BTREE index. Here is what you would need to do:
Let us know how this works out or if you have any more questions.
We are running version 9.2.1.
I did as you directed and clicked on the Update DBT for both Quickdex and Rightdex. For both of them I installed the index. This tells me that we were not using either one right?
After uninstalling after I installed them. I was still unable to create a Btree index for the same reason. I believe this table was in arev based on the location of the table location. I don't know if this is an issue.
What do you recommend now.
Thank you
User: Mark Mayfield
Correct, your results suggest that neither one existed on the table. Thus, as I suspected, something unusual is going on with this table.
It should not matter that this was originally an AREV table, unless the AREV table is pre-AREV 3.x. I doubt this is the case or you would have had other problems within OpenInsight by now.
There is another possibility that I did not originally consider. Usually a quick/rightdex is added to the data portion of a table. This is what the Table Builder tool does. However, on occasion developers will create a quickdex on the dictionary portion of the table. This can be done/undone using the Set_MFS subroutine.
Before you delve into exploring this subroutine and writing code, there is a simple way to confirm the existence of a quick/rightdex: a row named %RECORDS% is added to the table. So you might want to use a system editor to see if this row exists either in the data table (unlikely based on what you reported) or the dictionary table. If you find it then we still need to remove the quick/rightdex. If you do not find it then we are back to square one.
I opened all 6 files in note pad and found one that had the following data.
%RECORDS%%FIELD.COUNTER%þ%FIELDS%þ%INVOICE.NO*SEQ.NO%þ%LOCAL.GROUP%þ%PROTECT.SPEC%þ%SK%þ%WINDOWS%...
It was in the .OV file for the filename.
Is this what you were looking for?
User: Mark Mayfield
Yes, this is what I was looking for. However, I think you mistook my suggestion to use a "system editor" for a "text editor". I meant the OpenInsight editor (which there are three: System Editor, Editor+, and Editor++.) Then there is our own SRP Editor which we obviously consider to be better than all of them. ;-)
Well the information you posted tells me enough. It is clear that the quickdex was added to the dictionary table. The other items listed - %FIELD.COUNTER%, %FIELDS%, %SEQ.NO%, etc. - are all dictionary specific rows.
Okay, well the good news is that I think we have found the cause of your BTREE index problem. The bad news is that you will have to delve into Basic+ code to remove the quickdex. As mentioned above, you can use the Set_MFS routine to do this. Actually, you can do this without actually writing code. You can enter this single command in the System Monitor as such:
RUN SET_MFS 'DICT.foo', 'QUICKDEX.MFS', 5
Replace foo with the actual name of your table. I think it is probably optional for you to add the quickdex back since it is unlikely this was done for the end user application. This is usually done for the benefit of the developer. But if you *did* want to add it back then just enter this:
RUN SET_MFS 'DICT.foo', 'QUICKDEX.MFS', 1
That fixed it. :-) I am not going to re-install Quickdex unless we see some side effects.
Thank you for your quick response.
User: Mark Mayfield