I'm having exactly the same problem also with a large dataset (imported from an Access table). This is a fault that was supposed to have been fixed in 6.10, but it is definitely still occurring for me in this case. Thing is, I've imported a selection of the same data from an Excel table and it is grouping the records correctly. I'm just now trying to analyse whether it's the data that's causing the problem or Recorder itself.

I'll keep you posted.

Hi

Charles - please let me know if you can't spot anything in Access file that would cause this and I'll raise with Dorset Software.

Many thanks,

Just a quick update on this. I've now managed to get the data to import correctly after many, many, many tries. The solution was to split out the moth data I was importing into a separate import.

I eventually noticed that moths seemed to be the problem because they weren't collapsing, but other taxa were.

By importing the moths and the other records separately, everything collapsed appropriately under relevant samples. I've no idea why the mixed import is breaking, but it seems related to large numbers of moths. Perhaps because so many moth occurrences appear under one sample, as is often the case with light traps. I don't know, but there's obviously some obscure bug at work here.

Hi Les

Sorry to hear that you are having problems with this too.

Originally Charles sent me the import file but I was unable to reproduce the problem here - even with the large import the survey events/samples were created correctly. Myself and Charles have tried different variations - withholding columns and matching locations differently etc. but none of this seems to make a difference - Charles was still getting the wrong results and my import seemed ok.

Charles has now provided me with a full copy of his database and I too can reproduce the problem with this database.

So it appears the problem is database specific, but not specific to Charles' database!

The next step is to ask Dorset Software to take a look at problem, or perhaps suggest some checks that I can make here.

I'll keep you both updated,

Best wishes,

Hi Les,

Unfortunately this isn't just a display thing otherwise it wouldn't be such a problem. New entries are actually being created in the survey_event and sample tables for every single record. I've sent Sarah some test data so hopefully the problem will be fixed in the next version. Unfortunately that won't help with anything you've imported already.

In theory, though, it shouldn't be too hard to create a routine that fixes things. Mike Weideli is coming down here next week and so I'll speak to him to see how easy it would be to create a temporary post-import patch script.

Hi all,

Regretfully this issue I posted back in 2007 may still be a problem. Having just ran a couple of summary reports for my CEO (Events per Survey and Occurrences per Survey) a query was raised with respect to the number of occurrences per event which was very low at 4.

I checked some of the Surveys and unfortunately I found the same problem I originally reported with the correct grouping of events and occurrences. Can anyone else concur this with other datasets?

Hi Les,
I think this was a conscious decision of the import tool, because to correctly detect the existing samples for any new data would mean running lots of queries against the main database during import and hence would slow down the import massively.
Best Wishes