Lynn

Re Map Mate data - The Abundance/sex stage  part seems ok, but I am not too happy about the ideas on the name.  This seems a big departure from the principles of  Recorder. I think we should be encouraging the proper use of names rather than encouraging an inferior approach. Once you start going down this route then you are effectively abandoning the Recorder model.   Also from a practical point of view, you would have to increase the length  of one of the fields (Surname ? ) considerably to take the data or create a new field in the individual table to hold the unparsed names.  Would it not be beter to look at improved ways of parsing the map map names ? 

With regard to Recorder 3. The procedures provided are a bit complicated, but no more than neccesary to do a reasonably accurate transfer.  There are a few bugs in the conversion software which don't stop it working, but which produce  inaccurate results. There are also  number of things it doesn't do to Recorder 6 standards.  However,  generally the process is  fairly robust except where  the original data has been corrupted in some way, or is not in a standard format, which is most likely to have occured with larger systems.  There is little consiststency  in the problems encountered so it may be difficult to deal with these in the automated process,

With Recorder 2002, most of the problems seem to be with corruptions caused by early version of the import wizard, which didn't work properly. It would be possible to define a number of pre-import checks which would highlight these problems so that that can be corrected either automatically, if possible.or manually if not.
 

Mike.     

.

Hi Martin,
That's a good idea, and one which I have implemented in Indicia. It can be quite useful to allow an "external id" to be associated with each record so that if the record comes from an external system you have a unique reference to the source. It makes future synchronisation of data much easier.

Best Wishes

The Recorder import of MapMate, data does in effect retain the MapsMate key so new imports will update existing records rather than creating new ones.  This should work fine with the main Record (Taxon_Occurrence), but can run into difficulty with fields which need to be parsed (eg names). In these cases if the MapMate data is changed  (ie adding or deleting  or changing what is there) the keys generated may not be the same for the new import as the original. This can give rise to anomalies. However, data is not that often changed so this isn't  perhaps  that big a problem in reality.

With large MapMate datasets it can take a long time to get them into a format which Recorder can import so there is scope for improving the import process, by being able to accept MapMate fields without the need to manipulate them. This applies  particulary to abundance, sex and stage where Recorder should be able to process these fields without any prior manipulation.   The free format nature of the MapMate recorder name, where all sort of combinations and orders are possible within the same file,  makes this particularlly difficult to deal with. Nevertheless, I don't think it would be right to just accept the MapMate name unparsed into an existing Recorder field.  Possibly an additional field could be added to the Sample to hold the names of the Recorders in the MapMate format  (I think there may already be an unused field in there called Recorders ). The Sample and Survey Events Recorder could then use a generic name  (Sundry ?). It would then be posible  add the unparsed field into the Recorders field on report output by making a minor adjustment to the UDF which does the concatenation.         

With data from other sources, retaining some sort of external id would  be a good idea.

Mike

My reply was in reference to the original post by Lynn which was suggesting improvements to Recorder.

If only the same could be said of Recorder.