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

RevMedia FKB

Document	V4I6A18
Title	Using One Dictionary With Multiple Tables - Aaron Kaplan - SoftMart Inc
Keywords	DICTIONARY DICT
Text	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; OriginalTableNameOriginalVolumeOriginalAccount 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)

[revmedia/copyrigh.htm]

Page last modified: 08/02/03