Hi Charlie,

See response from Stuart Ball below:

The MapMate -> Recorder transfer scheme I devised uses the MM report generator’s user supplied SQL option to output a tab delineated text file from MM which has one row per record and includes the MM record key in the output. This file is then imported using Recorder’s Import Wizard. One of the options this offers is to translate MM keys into NBN keys.

Each copy of MM has a “cuk” (copy unique key). For example, the Hoverfly Recording Scheme’s cuk is “5pv”. MM generates a “guk” (globally unique key) by generating a random string of 3-6 digits and lower case letters (except “e”) and then suffixing them with the cuk. So a guk looks something like “vsnrf5pv”. (NB. MM keys are lower case.)

Each copy of Recorder has an 8 character SiteID e.g. “JNCCDEV1”. Recorder generates a unique key using a running, 8 character code consisting of digits and upper case letters for each table. A key is formed by prefixing the next available running code in sequence with the SiteID, so NBN keys look like “JNCCDEV10001A023”, “JNCCDEV10001A024”, etc. (NB. NBN keys are upper case.)

The Import Wizard forms an NBN key from a MM key by:
1.    Removing the guk (i.e. the last 3 characters of the MM key), force them to upper case and prefix with “MMEEE” to make an 8 character SiteId – MMEEE5PV (“MM” for MapMate and “E” s because they are not used by MM for its keys).
2.    Force the remaining characters from the guk into upper case and pad them out with leading “E” s to 8 characters – “EEEVSNRF”.
3.    So “vsnrf5pv” becomes MMEE5PVEEEVSNRF.  (Note that it is possible to reverse this process and get the original MM guk back again!)

The import wizard will then save the TAXON_OCCURRENCE, TAXON_DETERMINATION and TAXON_OCCURRENCE_DATA rows derived from the MM record using this key (Recorder’s keys are only unique within a table, so this same key can be used for all of these entries with no problem). MM can only store one abundance entry per record so only one TAXON_OCCURRENCE_DATA entry is ever needed.

So, in the first case, the MM user has changed the abundance for a record and re-imports it into Recorder. The same Recorder key will be generated and the imported entry will be detected as a duplicate by the import process. If the user chooses the “All Imported” option to deal with duplicates, the changed MM record will overwrite the one previously imported (which is the desired outcome). If they choose “All Original”, the incoming, changed MM record will be discarded and the previously imported version retained.

However, some of the associated information – recorder, determiner, species, etc. are not handled like this. During the Import Wizard’s matching process, items from MM are matched to those already in Recorder. E.g. if the recorder in MM is “Stuart Ball”, this name will appear in the people matching screen in the Import Wizard and will either be matched to an existing entry for a person in Recorder (which doesn’t have to be identical – it could be matched to “S.G. Ball”), or a new person entry will be created by Recorder. Neither of these possibilities (existing or new) will have any link with the MM entry and will have a straightforward Recorder key. If you re-import the MM data, presumably, you will make the same matches as before. If you had subsequently noticed that “Stuart Ball” was a duplicate for “S.G. Ball” and merged them in Recorder, hopefully you would remember this and act accordingly next time you did a MM import. But there is no automated way to remember this for you or enforce it (so you may end up creating “Stuart Ball” again and then having to notice and perform the merge again in future).