I'm working on an AREV3.12 application. I'm working on a process to copy certain tables from one application to another (from a live app to a training app). When I test the process everything seems to go well. I check the !file to make sure everything is in place and that it has the right volume label and all. I check the row count thru a DUMP and that is right. I've checked the DICT entriers for the table and they look right. I use one of our browse programs on the test table and it works just fine. The rub comes in when from TCL, I go F10, DB ADMIN, INDEXES, UPDATE, UPDATE ALL INDEXES IN A SPECIFIC TABLE. At this point I get the error message:

B173

NO COLUMNS ARE INDEXED IN table_name.

I check the settings of the two index definitions (one is BTree and the other is CrossReference) and they both are set to YES and look good. I assume that there is some sort of flag that hasn't been set that the UPDATE ALL INDEXES IN A SPECIFIC TABLE looks for and isn't finding. I've also logged out of the application and then back in and still get the same error message.

In my process of coping a table from one app to another, I redo all of the indexes on the table by using the REBUILDINDEX_SUB routine.

I might not be seeing the information right in front of my face as I reread thru the different Knowledge Base and On-Line Discussion items I've printed out. Can anyone point me in the right direction? What does the system process that updates all indexes in a given table look for in determining if there are indexes or not on the table?

Thanks,

Michael Slack

Michael;

I do not know the reason why the indexes are not showing.

However here some places to check to make sure they are shown as on/existing.

Updating the Dictionary

The indexing system maintains a variety of information in the dictionary record of an indexed field. Depending on the type on indexing, different information is maintained. You will have to edit the dictionary record for each field in the file that was indexed: Warning! Do not use Ctrl-D (delete a line) or press Enter while editing a dictionary record. This will alter the dictionary record, making it unusable. To edit a dictionary record, enter from TCL:

EDIT DICT.FILENAME FIELDNAME

Btree Indexes

Field 6 of each dictionary record tells the system whether or not this field has a Btree index. If there is a 1 in this field, the field has had a Btree index installed. Change the 1 to a 0 and save the record.

Cross Reference Indexes

When a Cross Reference index is placed on a field, a symbolic field is created to maintain the index. This field can be identified by the .XREF extension. Because this field is no longer required, it should be deleted. If a cross reference index is placed on the field again, the symbolic field will be recreated. In addition, a field with a Cross Reference index has the name of the cross reference symbolic in field 22 of the dictionary record. Position the cursor on line 22 of the dictionary record, press Ctrl-X, and save the record.

Relational Indexes

Relational indexes use several fields in the dictionary record to store their control information. In the record that serves as the target of the relational index, change the 1 on line 25, which tells the system that this field's data is protected, to a 0. Line 24 contains the name of the relational index, which should be cleared with Ctrl-X. To completely remove the Relational index, the dictionary of the source file must also be edited. In that dictionary, the source field will have the name of the related field on line 23. Remove the name withCtrl-X.

Final Steps In Advanced Revelation 2.0 and higher

There are two other records in the dictionary that should be deleted:

%PROTECT.SPEC% and %FIELDS%. Delete these fields after editing the indexed fields. Reattach the file and the system will recreate these records, reflecting the changes made to the dictionary. At this point the file has had all indexing removed. Indexes can be re-established as necessary.

This information was taken from an article on REMOVING INDEXING MANUALLY (TB#56) - Removing Indexing Manually in the KB.

I Hope This Helps you

JoeD

Hello Joe:

Thank you for you suggestions but I must not have explained myself well enough. I'm familair with the manual removal of indexes so I had no problem following your directions as far as looking that the proper values where in the righ columns in the dictionary rows. Everything looked to be in place. The thing is that my ultimate aim is to copytable from one application to another and then rebuild all of the indexes in the newly copied table, all of this thru a program. I'm writing the program in such a way that our trainer (who isn't versed in some of the procedures that are needed to copytables and rebuild the associated indexes) only needs to do a couple simple things before selecting a menu items that kicks off the program which does everything else for them. At this point everything is in place and seems to work right. Except for updating the indexes after the indexes have been rebuild. If I can find a way of making sure everything is in order after the process is complete, I would perfer that. Bein

g forced to remove and rebuild the indexes by hand, defeats the aim of the program I'm trying to build.

If you have any suggestions as to where I might look to check settings and/or flags related to indexes, that would be a help. I'll continue to reread the documentation I've been able to find so far. I'm thinking that if I just need to make sure certain flags are set, that I can do that thru the program and remove that process from being forced onto the user or someone else.

Thanks,

Michael Slack

Make sure that the dict, data and !xxx files are all on the same volume.

Make sure also that these files are all in the same application (i.e. GLOBAL).

If the files were copied or moved or renamed at some time in their life these might have gotten out of sync.

It's also possible that there are duplicate dicts or !xxx on different volumes that get switched during login attaches.

I've gotten the same error message in 3.12 when the dict was assigned to the application and the data to "GLOBAL".

Does the file have SI.MFS attached? If you do a LISTMEDIA/LISTVOLUME of the volume containing the file is there an SI.MFS in the MFS column?

Hello Warren:

Thanks for the info.  I checked and double check that all of the tables had the right volume label and were in the right application and all.  Everything looked to be in place.  The response from Paul Rule pointed me to my problem.  I was missing the SI.MFS in the REVMEDIA rows of the effected table.  My initial testing suggests that all I'll need to do is write some code for my program to make sure that the SI.MFS is in the REVMEDIA and everything should be happy.

Thanks for your help,

Michael Slack

Hello Paul:

It looks like you hit the nail on the head. When I checked my REVMEDIA rows for the effected tables, they didn't have SI.MFS listed. I then added it to the rows and the UPDATE INDEX now works just like it's supposed to.

I'm going to add some code to my program to check for the existance of SI.MFS in the REVMEDIA rows of the tables that I'm working with. If it's not there then add it, otherwise make sure that it's last in line.

I guess the root of my problem was that I assumed that the REBUILDINDEX_SUB process would take care of that for me and obviously it didn't.

Thank you,

Michael Slack

Thanks to everyones help, I found what was causing my problem. It's was the COPYTABLE process. As mentioned in another set of discussions, the COPYTABLE in part does a MAKETABLE. This creates a new REVMEDIA row for the table that is being overwritten (along with a new DOS filename). The problem comes in that if there are any MFS's on the old REVMEDIA row, they don't get copied over to the new REVMEIDA row created by the COPYTABLE.

So in my case, I did a copy table and rebuild the indexes (if need be) and thought that was all that I needed. When I checked the definitions of the indexed columns they looked good. When I used the indexes in my application they worked right. When I went to update the indexes thru the AREV menu option, I got the message saying that there wasn't any columns indexed on that particular table. The reason for that message was that the SI.MFS was missing from the REVMEDIA row for that table.

What I did to correct that was righ before the COPYTABLE, I read the REVMEDIA row for the table. Then after the COPYTABLE, I read the new REVMEDIA row for that table and updated it with the list of MFS's from the original row and wrote it back to REVMEIDA. Then I went on to use the INDEX_REBUILDER process (that uses the REBUILDINDEX_SUB) that Warren was kind enough to give me. At that point all was right with the world.

Thanks All,

Michael Slack

I believe somewhere in the ALL.ZIP of utilities in the download section is INSTALL.MFS, a handy little utility that you can use from the command line to add/remove or reorder MFS entries in the REVMEDIA records.

View this thread on the forum...