AREV3.12 BTREE INDEXING PROBLEM (AREV Specific)
At 02 OCT 1998 10:21:38PM APROGRAMMER wrote:
Here's the problem:
After saving a new row to a table we can pull up the data - no problem.
However, when we try to locate the data on a browse screen, it's not
there. This, of course, indicates that the data has not been indexed.
We have confirmed this by checking the !TABLE 0 record immediately
after saving a test row and found the 0 record empty except for the zero
on the first line. We checked !TABLE 1, 2, 3 and so on as well.
Doing an update on the indexes does not help, but if we do a rebuild
we can then browse and locate the data. However, the next time a
new row is saved it will not be updated.
The table in question has several indexed fields (all BTREE) with two
other MFSs in addition to the SI.MFS attached to it. These have all
worked in the past and we have learned from experience to place
these MFSs in front of the SI.MFS on the second line of the
REVMEDIA table as: X.MFS²Y.MFS²SI.MFS
Otherwise, the SI.MFS blocks the other MFSs and they will not work
correctly.
The arguments being passed through the MFSs are
(CODE, FS, FILEVAR, ITEM_ID,FMC, ITEM,FLAG). We have run
several tests to monitor the values being passed and on the WRITE
process the FLAG=1 or success. This, of course, is correct because
as I mentioned earlier, the data is being written to the table.
Our organization has multiple sites utilizing different platforms and the
problem is occuring at these sites as well. Therefore, we are assuming
this is an AREV issue.
Any insight into this problem will be greatly appreciated.
At 03 OCT 1998 05:12AM Jonathan Bird wrote:
How about checking the table for keys that may meet one of the following:
1. Contain a value mark or field mark.
2. Are longer than the length defined for the out puit of the key field in the dictionary
JB
At 03 OCT 1998 10:04AM Aaron Kaplan wrote:
Could be that the index volume reference isn't matching the volume pointers. This is in the !FileName record of !File. Validate this information then delete the ! record in the !FILE, detach and re-attach the table.
Since you're doing rebuilds, you might try a full and total remove first.
At 05 OCT 1998 12:14AM Curt Putnam wrote:
Try removing your mfs's. If indexing works, the problem is yours.
At 05 OCT 1998 11:26AM Aprogrammer wrote:
Have already tested by removing all MFSs except SI.MFS and the
problem remains.
At 05 OCT 1998 12:34PM Terry Rainville wrote:
I believe Jonathan hit the nail.
I think it sounds like a Index field with length being too short.
Seems to me I ran into that once or twice before myself.
Also check the delimiter thing in the keys he mentioned thats also important, I have a subroutine for this if you need it.
The other thing that hit me is Indexing Symbolics.
If the field is a symbolic relying on information from another
table then the index will never rebuild intself.