In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
  
Home page Home page Home page Home page
Pixel
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
Pixel

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.


0001    SUBROUTINE BFS(CODE, BFS, HANDLE, NAME, FMC, RECORD, STATUS)
0002    /*******************************
0003      ö VERSION    : 1.0
0004      ö PURPOSE    : Use another table's handle for this table
0005      ö AUTHOR     : Aaron Kaplan
0006      ö CREATED    :
0007      ö THEORY OF OPERATION :  The MFS checks a table called MULTI_DICTS for
0008                               the existance of a row.  If so, that table is
0009                               opened in place of the table calling this MFS.
0010                               This has the effect of substituting the data
0011                               in the alternative table with that of the
0012                               original.
0013       EQU COPYWRITE$  TO 'Copyright 1992 by Aaron Kaplan All rights reserved'
0014    */
0015      EQU TRUE$       TO 1
0016      EQU FALSE$      TO 0
0017      $INSERT INCLUDE, FILE.SYSTEM.EQUATES
0018      $INSERT INCLUDE, FSERRORS_HDR
0019  
0020      FS = DELETE(BFS,1,1,1)
0021      NEXTFS = FS<1,1,1>
0022      @FILE.ERROR = ""
0023      $INSERT INCLUDE, FILE.SYSTEM.ONGOSUB
0024    RETURN
0025  
0026    OPEN.TABLE:
0027      VOLUME = XLATE('FILES', NAME[1,'*'], 1, 'X')
0028      MULTI_DICT_KEY = NAME : "*" : VOLUME
0029      OPEN 'MULTI_DICTS' TO MULTI_DICTS_FILE THEN
0030       READ REC FROM MULTI_DICTS_FILE, MULTI_DICT_KEY
0031    THEN
0032        NEW_NAME = REC<1>
0033        NEW_VOLUME = REC<2>
0034        NEW_ACCOUNT = REC<3>
0035        EXISTS = XLATE('VOLUMES', NEW_VOLUME, '', 'X')
0036        IF LEN(EXISTS) THEN
0037         VOLUME_FILES = EXISTS<3>
0038         HANDLE = EXISTS<5>
0039         NAME = NEW_NAME : "*" : NEW_ACCOUNT
0040         CALL @NEXTFS(CODE, FS, HANDLE, NAME, FMC, RECORD, STATUS)
0041        END ELSE
0042         STATUS = FALSE$
0043        END
0044       END ELSE
0045        FLAG = FALSE$
0046       END
0047      END ELSE
0048       STATUS = FALSE$
0049      END
0050    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)
Pixel
Pixel Footer R1 C1 Pixel
Pixel
Pixel
Pixel