Recorder can relate mutiple records to just one record. That is to say a number of differnt fungi records could be related to just one beech tree record, however, while this is possible via the Organisation hierarchy using drag and drop,  the Import Wizard isn't sophisticated enough to deal with the situation.

I don't think anything can be done to get around this in the import wizard, but a batch update which sorts it out after import would be a possibility.

A bit more consideration Mike

I have just looked at the data and fortunately the worst examples are all in a single survey of fungus records. There are nearly 17,000 survey events in this survey, but if i create a query which groups the events by LOCATION_KEY, LOCATION_NAME, SPATIAL_REF and the three VAGUE_DATE fields, this figure is reduced to 1094 distinct events (most of which contain multiple samples, which include both duplicate tree species as associates and duplicate biotope records as well), which give an indication of the scale of the problem. Ideally I would also like to group by COMMENT, but my test query in the Access db will not allow grouping by text fields (I think this is probably a restriction of SQL Server or of ODBC).

We are doubly fortunate since all of this data derives from a single recorder so that is at least one complication I do not have to worry about. I am wondering if you have any idea of a cunning way I could overcome the difficulty in the possible case where there were multiple recorders for any of the samples. I can only think that I would need to step through each of the suspected duplicate survey events ensuring that each has exactly the same event recorders associated, or perhaps create a function which sorts and concatenates recorder name keys and group on that as well.

After that I guess I would have to step through the events, checking the samples within for similar correspondences and where I find duplicates would then need to transfer all the occurrences to the first sample within the first event of each group.

After that I would then check each resultant sample for duplicate occurrences, check each occurrence to see if it is recorded as a related occurrence and reassign all the related occurrences of a given taxon to a single example, marking all the others for deletion (perhaps setting the determination/validation fields appropriately?)

Finally I would need to ensure that each of the marked occurrences now no longer features in any related occurrence, before deleting them and any associated determination records etc.

Writing this message has just reminded me why I haven't attempted it yet. And none of this answers Hilary's question as to what she should do with new data of this type. As far as i can see, the only sensible option for importing large datasets of fungus or lichen data is to relegate  the associations to a comment field. This is a major deficiency in the import wizard, since it gives the impression that it can import related occurrences, but what it actually does is hugely overcomplicate the organisation of data imported.

Thanks again Mike

I know that we would, but if you don't have time I am sure I will get round to it eventually.

Thanks David, we are not talking about importing MapMate records, the problem with MapMate comes when we export data to MapMate users (since MapMate rejects what it considers to be duplicate records - those having the same location, spatial ref, date and recorders).

Import of fungi records from excel has generated multiple tree species records within a survey event, but interestingly, following Mikes comment above and yours, I suspect there may be something else going on.

Looking at the data as it has imported, the import has generated multiple duplicate samples within a given survey event, each of these samples contains no duplicate tree species, but because there are many samples, each with (say) a record of Beech, we end up with records which look, to MapMate like duplicates.

I seem to recall a discussion on here of the tendency to produce multiple unnecssary samples and that the problem was addressed in an earier upgrade (can't find the relevant discussions right now though. We do have a number of known problems with add-ins on the workstation used to import these records, so it may be that the fault is machine- (or possibly user-) specific and not directly related to the asociated species data.

I will investigate further and see what I can learn...