If the user is modifying data in a portal, then it might be the case that the other portal records (and the parent) may also be edit locked. I'd need to test or research that one to be sure, but I seem to recall, a number of versions ago, that this was the case.
any "batch update" of multiple records--whether an import with the matching records option, replace field contents or a looping script is best done at a time of day when no one is accessing the database and editing data.
You may be able to find the records you want if you have a timestamp field that auto-enters a modification timestamp.
You might be able to perform a find for all records that should have been updated but which do not have the correct value in this timestamp field.
The ultimate method for this is to add a "lock" field where you script first sets a value to this field for all records that might be updated by your import to lock out all other users and check for any that can't be locked because another user already has it opened. Privilege set options can set up a lock expression that deny edit access to the fields of the table as long as the lock field's value is set on that record.
We are using portals...I thought that might have been the issue. We already timestamp records that are imported (this is how we've been figuring it out) Not the easiest way, but it works. I will have to look into the lock field method.