REVMEDIA FKB Articles - AREV, OI, REV G, jREV, JCDC, LIVEWATER,ADVANCED REVELATION, OPENINSIGHT, REVELATION G

RevMedia FKB

Document	V1I3A3
Title	Make.Index
Keywords	MAKE.INDEX FILECOPY BTREE XREF RELATIONAL INDEX CAPTURE
Text	When moving files around the system I'm sure that you could not help but notice that a FILECOPY removes all INDEXES on the destination file There is some logic in this but it can make life really difficult when trying to install new versions of software how can we reinstall the missing indexes? I know that when I first had this problem I just developed CAPTURE scripts to call up the main menu go to Files Indexing Update etc etc This was a mess More often than not a "Stickum" on the menu would get in the way and my system would sit there flashing at me as the wrong characters got fed into the wrong screen I thought that there had to be a better way and started playing around What I thought must be an easy process turned out to be more complex but it all revolves around a system subroutine called MAKE INDEX (A routine that puts all the extra necessary pointers and records onto the system to tell it that it has an index on a field (or to remove it)) The CALLING syntax is for MAKE INDEX is CALL MAKE INDEX(File Field name Old record New record) where File name of the file the index is on Field name dict item in the file Old record compiled dict item before the index was added New record compiled dict item AFTER the index was added As you will be aware FROM the documentation on the utility diskette indexing information is stored in various fields on the indexed dictionary item When the dictionary item is filed away DICT MFS recompiles it and adds the new OBJECT code back into the item before writing it away BTREE INDEXES A BTREE index is one of the most easy to set up A dictionary item WITH a BTREE index is distinguished by the presence of a 1 in field 6 Thus to add a BTREE index to a field we would read in the dictionary item for the field add a 1 into field 6 write the item out again to recompile it then read it in to a new variable and call MAKE INDEX E g (assuming no errors encountered) DECLARE SUBROUTINE MAKE INDEX FILE = "DICT USERS" ITEM = "SURNAME" OPEN FILE TO DICT THEN READ REC FROM DICT "SURNAME" THEN REC<6> = 1 WRITE REC ON DICT "SURNAME" READ NEW REC FROM DICT "SURNAME" THEN MAKE INDEX(FILE ITEM REC NEW REC) END END END XREF INDEXES This is of necessity the most complicated index to set up When you set up an XREF index a new SYMBOLIC field is added into the dictionary which is used to do the XREFing This field has the name field name XREF and contains a call to the system routine XREF WITH the necessary STOP list and delimiter information Thus to add an XREF index to a field we must first CREATE this extra dictionary item AS WELL AS altering the original dictionary item to tell it that an XREF index exists by adding the name of the symbolic xref item into field 22 of the original dictionary item Thus (assuming setup as above) OPEN FILE TO DICT THEN READ REC FROM DICT "SURNAME" THEN GOSUB CREATE XREF MAKE INDEX(FILE ITEM "" REC XREF) REC<22> = ITEM : " XREF" WRITE REC ON DICT "SURNAME" THEN READ NEW REC FROM DICT "SURNAME" THEN MAKE INDEX(FILE ITEM REC NEW REC) END END END RETURN CREATE XREF: * * Generate XREF item here call it REC XREF See listing for logic * WRITE REC XREF ON DICT ITEM : " XREF" READ REC XREF FROM DICT ITEM : " XREF" ELSE * ERROR handling END RETURN RELATIONAL INDEXES This is nearly as simple as BTREEs it merely requires that the dict item be told what it is RELATED to by putting filefieldsort order into field 23 Thus USING the above EXAMPLE to relate the surname field to NAMES file in the KEYS field in ascending numerical order (assuming setup as above) OPEN FILE TO DICT THEN READ REC FROM DICT "SURNAME" THEN REC<23> = "NAMESKEYSAR" WRITE REC ON DICT "SURNAME" READ NEW REC FROM DICT "SURNAME" THEN MAKE INDEX (FILE ITEM REC NEW REC) END END END (Volume 1 Issue 3 Pages 4 9)

[revmedia/copyrigh.htm]

Page last modified: 30/01/03