RIMMF Updates

NEEDS UPDATING

The RIMMF software will be updated often, to:

• fix problems
• update the default tables
• add functionality, and
• implement suggestions

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

• elements
• vocabularies
• vocabulary terms

The default tables are updated whenever RIMMF is updated.

By user customizations, we refer to:

• records and templates created by the user
• elements, vocabularies, terms added by the user
• elements, vocabularies, terms modified by the user

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.

The following flowchart illustrates the processing 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:

1. replace the default tables from the existing version with new default tables
2. load the new default tables into the RDBMS
3. if the user has modified the default tables“
   1. overlay those modifications on the default tables
   2. apply the change log for the current version to the default tables
   3. save the result (which becomes the default the next time the program starts)
   4. update the ESID (so the update steps do not run the next timne the program starts)
   5. restart the program
4. if the user has not modified the default tables, or, the ESID has not changed:
   1. check for elements, vocabs, terms added by the user
   2. add the user-added data to the default tables
5. run the program

In the above design, it is possible that some user 'mods' may be undone during an update. The reason for this is:

1. RIMMF does not track user modifications made to the default tables at the field level; user 'mods' are only recorded at the record level.
2. Changes made by TMQ to the default tables take precedence over user modifications to the same element, vocabulary, or term.

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:

1. the new default tables are installed
2. your mods are applied to the default tables (preserving your change to the term)
3. the version change log is applied (overwriting your change to the term)

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.