RevMedia

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.

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.