Well, I went and tested this on our network. Opened a record (cursor in a field) in FileA on another user's computer, and then found a set of records from the FileA (including the open record) on my workstation.
Went to FileB and imported the current found set from FileA. Error capture is on in FileB. No errors reported. The open record was not imported. All the other records were imported. The entire record was not imported, it did not create a new record and then fail to update some of the fields - nothing came across. Can't understand why the open record could not be imported, if not committed, then what is there at the time of import should be available for import? And no warning. -----Original Message----- From: FileMaker Pro Discussions [mailto:[email protected]] On Behalf Of Steve Cassidy Sent: 30 June 2011 07:25 To: [email protected] Subject: Re: Import / locked record 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=
