The RIMMF software will be updated often, to:
Although RIMMF was designed to facilitate frequent updates (Check for Updates), there are a few details that we still have not worked out regarding user customization of the default tables.
In short, in the current version (RIMMF 1), updates we make to the default tables may overwrite changes made by the user to these tables via the Element or Vocabulary editors.
Records and templates that you create will never be overwritten, nor will any elements or terms that you have added yourself. The problem only pertains to elements, etc., that already exist and have been modified by the user.
This page tries to explain what is going on.
By default tables, we refer to the three data files that are distributed with RIMMF that contain the definitions needed to support our implementation of RDA
The default tables are updated whenever RIMMF is updated.
By user customizations, we refer to:
Note that RIMMF makes a distinction between elements, vocabularies, terms added by the user, and values from the default tables that are modified by the user.
The first two items –your records and templates, and your elements, vocabs, and terms– are never changed when RIMMF is updated.
It is the third item in this list –changes you make to the default elements, vocabs, and terms– that may be lost during an update.
Version check: an internal routine that checks whether the format of any tables have changed, or whether the ESID (element set ID) has changed –in the latter case, a change log will be available (the change log contains a list of each individual change we made to one of the default tables)
If the format of any of the tables has changed, these tables will have to be defaulted. We have not had to do this yet, and if, or when, we do, we will no doubt need an import routine that will preserve any mods from the earlier version of the tables.
If the ESID has changed, which has been the case with each RIMMF update so far, then the following actions take place:
In the above design, it is possible that some user 'mods' may be undone during an update. The reason for this is:
For example, say that you have modified a vocabulary term using the vocabulary editor. This change is saved in your 'mods' to the terms table, and is always present when you run RIMMF. Later, a new program version is released and you upgrade your RIMMF. In this new version, there is also a change to the same term that you changed earlier. If this is the case then, following the flowchart above, we see that:
If you have heavily modified the default tables, and lose your changes to an update, you should contact us for assistance. RIMMF creates a backup copy of your 'mods' in the folder:
My Documents\RIMMF\tables\_history
and from these backups we should be able to restore your changes; though you may need to revert to the prior version to do this.
If you are customizing the default RDA elements, perhaps to experiment with mapping to MARC or mapping from MARC, there are two precautions you can take to preserve your changes.
First, in the 'tables' folder, where RIMMF store the tables used by the program, you will find filenames that contain '-mod' in them. These '-mod' (modification) files contain your customizations to the default tables. RIMMF will copy these files to the '_history' folder everytime it runs, but they may be removed from the runtime folder after an update.
You may take the precaution of backing up these files before an update. And then, you might try copying them back into place after an update.
Another way of achieving the same end would be to respond 'Ignore' to the prompt that appears duringthe update process itself, and asks you if you want to update the tables.