Using One Dictionary With Multiple Tables - Aaron Kaplan - SoftMart Inc

This article is in response to a thread a while back on Compuserve concerning the old Rev G ability to have more than one table accessing the same dictionary. That seemed like a functionality that I could use so I decided to think about a way to implement this. Suddenly the answer appeared in a vision. If I place an MFS on the dictionary table, I could intercept the open call, open a different table in its place, and the system would never know the difference. Simple, elegant, and a bit too easy. My first attempt was a stunning success, which frightened me. I decided to be brave and shoot for the whole works. Let's try indexing and create an index. Bad move. After the index was created on one table, the other table attempted to access it also (as it should). However, since there was not a !table for the second table, the system fell flat on its face. After that, I decided that this little utility of mine must have its own indexing capabilities that would alleviate these problems in the future. So, during the code for the open, I had to check for the existence of indexes. I also needed to check that the indexing had not changed, i.e. create delete or modify.

In the end, this is how my system is designed. I maintain a table called MULTI_DICT. Make sure this table is the global account or you could find yourself without access to a table. The key to this table is a three part key; OriginalTableName*OriginalVolume*OriginalAccount. This is the table name, volume and account as it really exists in Revelation (i.e. what the table looks like in the Revmedia table). The rows also contain three fields ; AlternativeName, AlternativeVolume, and AlternativeAccount. The rows are entered using a template. Existence of the MFS is the first thing that is checked after the template is saved. If MULTI_DICT_MFS is not on the table, we begin to install it.

Installation requires two steps. First we must add the MFS to the Revmedia row. This has been explained hundreds of times (see Revmedia passim.) and will not be described here. After the MFS is installed, I attach the table. Here is where the MFS comes into play. The MFS is surprisingly simple. The only code takes place during the open call. Here the system checks for the existence of a row in MULTI_DICT matching the table, volume and account of the table being opened. If it exists, the name, volume and account are changed to the information from the MULTI_DICT table and this is passed on to RTP57 to open. The table handle and all other pertinent information is then stored in the Tables table. (For purposes of space, the following MFS code has had all of the dummy stubs and a lot of white space removed - Ed).

This will work with the quick attach routines that are currently in use. Since the image will regenerate itself when ever a Revmedia.* table is altered, the next logon session will reflect the changed table handle.

At this point, the attached table's dictionary is the new, alternative dictionary. I check through each dictionary row to determine if there is an index on the field. If the !table and the dictionary rows do not match, the row is updated through index.flush and make.index routines. See Revmedia passim for information on these functions.

If indexing has been changed on an existing table, one of two things will happen. The system will probably notice the addition of an index and will update the index the first time the table is accessed. But, for my own piece of mind, I installed a softkey off the entry template that will update the indexing rows using the methods described above.

  SUBROUTINE BFS(CODE, BFS, HANDLE, NAME, FMC, RECORD, STATUS)
  /*******************************
    ö VERSION    : 1.0
    ö PURPOSE    : Use another table's handle for this table
    ö AUTHOR     : Aaron Kaplan
    ö CREATED    :
    ö THEORY OF OPERATION :  The MFS checks a table called MULTI_DICTS for
                             the existance of a row.  If so, that table is
                             opened in place of the table calling this MFS.
                             This has the effect of substituting the data
                             in the alternative table with that of the
                             original.
     EQU COPYWRITE$  TO 'Copyright 1992 by Aaron Kaplan All rights reserved'
  */
    EQU TRUE$       TO 1
    EQU FALSE$      TO 0
    $INSERT INCLUDE, FILE.SYSTEM.EQUATES
    $INSERT INCLUDE, FSERRORS_HDR

    FS = DELETE(BFS,1,1,1)
    NEXTFS = FS<1,1,1>
    @FILE.ERROR = ""
    $INSERT INCLUDE, FILE.SYSTEM.ONGOSUB
  RETURN

  OPEN.TABLE:
    VOLUME = XLATE('FILES', NAME[1,'*'], 1, 'X')
    MULTI_DICT_KEY = NAME : "*" : VOLUME
    OPEN 'MULTI_DICTS' TO MULTI_DICTS_FILE THEN
     READ REC FROM MULTI_DICTS_FILE, MULTI_DICT_KEY
  THEN
      NEW_NAME = REC<1>
      NEW_VOLUME = REC<2>
      NEW_ACCOUNT = REC<3>
      EXISTS = XLATE('VOLUMES', NEW_VOLUME, '', 'X')
      IF LEN(EXISTS) THEN
       VOLUME_FILES = EXISTS<3>
       HANDLE = EXISTS<5>
       NAME = NEW_NAME : "*" : NEW_ACCOUNT
       CALL @NEXTFS(CODE, FS, HANDLE, NAME, FMC, RECORD, STATUS)
      END ELSE
       STATUS = FALSE$
      END
     END ELSE
      FLAG = FALSE$
     END
    END ELSE
     STATUS = FALSE$
    END
  RETURN

There is one thing you should remember while creating these tables. The MFS, template and all supporting programs work with the table name that is entered. Since this is primarily used for dictionaries, then dict.tablename should be entered. The programs do not assume the table is a dictionary nor does the program add 'DICT.' to any table name entered. Failure to do so could create some problems, the very worst is rebuilding of all indexes in the tables.

(Volume 4, Issue 6, Pages 12,13)