|
|||||||
Make.IndexWhen 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 INDEXESA 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) 0001 DECLARE SUBROUTINE MAKE.INDEX 0002 FILE = "DICT USERS" 0003 ITEM = "SURNAME" 0004 OPEN FILE TO DICT THEN 0005 READ REC FROM DICT,"SURNAME" THEN 0006 REC<6> = 1 0007 WRITE REC ON DICT,"SURNAME" 0008 READ NEW.REC FROM DICT,"SURNAME" THEN 0009 MAKE.INDEX(FILE,ITEM,REC,NEW.REC) 0010 END 0011 END 0012 END XREF INDEXESThis 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) 0001 OPEN FILE TO DICT THEN 0002 READ REC FROM DICT,"SURNAME" THEN 0003 GOSUB CREATE.XREF 0004 MAKE.INDEX(FILE,ITEM,"",REC.XREF) 0005 REC<22> = ITEM : ".XREF" 0006 WRITE REC ON DICT, "SURNAME" THEN 0007 READ NEW.REC FROM DICT,"SURNAME" THEN 0008 MAKE.INDEX(FILE,ITEM,REC,NEW.REC) 0009 END 0010 END 0011 END 0012 RETURN 0013 0014 CREATE.XREF: 0015 * 0016 * Generate XREF item here, call it REC.XREF - See listing for logic 0017 * 0018 WRITE REC.XREF ON DICT,ITEM : ".XREF" 0019 READ REC.XREF FROM DICT, ITEM : ".XREF" ELSE 0020 * Error handling 0021 END 0022 RETURN RELATIONAL INDEXESThis is nearly as simple as BTREEs, it merely requires that the dict item be told what it is related to by putting file*field*sort.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) 0001 OPEN FILE TO DICT THEN 0002 READ REC FROM DICT,"SURNAME" THEN 0003 REC<23> = "NAMES*KEYS*AR" 0004 WRITE REC ON DICT,"SURNAME" 0005 READ NEW.REC FROM DICT,"SURNAME" THEN 0006 MAKE.INDEX (FILE,ITEM,REC,NEW.REC) 0007 END 0008 END 0009 END (Volume 1, Issue 3, Pages 4,9) |
|||||||
| |||||||