On 30 Jun 2011, at 05:52, Peter Buchanan wrote:

> The record was created by UserB a few weeks before the import by UserA, so
> it cannot be an uncommitted record. 

However, if UserB was editing the record in question at the time UserA did the import, there would be uncommitted data. Since you are updating records in the import, if UserB had changed or was editing the match field then you might expect the import to fail altogether – depending on the updating options.

> Yes, the entire record fails to import.
> 
> There is no validation in File2 and but there is updating.

If there is updating based on a match field, how actually are you checking that the import fails to import the whole record? Is it possible that the import takes place, but there is no updated data to import?

> 
> I have no error capture, is there a specific code for "record open"?

I'm not sure about this, but if you don't have error capture on, then I think the import script step will provide an error message if there is a fundamental problem with the import (such as file not found or something).

However, as already discussed, 'record open' is not a possible error during import  – so UserB having the record open will not result in an error message. In fact, the import should complete just fine in this case. BUT the results may be unexpected (as in your case) because UserB may have changed but not committed some data. UserB may commit AFTER the import, so it might appear that the import brought in the wrong data.

Error codes: http://www.briandunning.com/error-codes/

In my experience, import using update options can be quite complex. I'm guessing that, with multiple users, you are seeing some of this complexity.

Steve