Peter, I've been following this thread and would like to offer some thoughts.
In order to Import *From* File 1, User A needs only Read Access to the records since User A is only reading the data in the Found Set records. It does not matter if one (or more) of the Found Set records is currently in an Open State by User B; the Open record's data, as it currently exists on the Server, will be sent to User A for use in the Import process. This also means that any uncommitted User B data changes to the Open Record will not be sent to User A since the Server does not have that updated information. [Note that the same holds true if User A is both the modifier of the record in File 1 and the Importer of data from File 1. In other words, if User A has modified a record in FIle 1 but not committed (saved) that data to Server, and User A wants to import that modified record into another table, User A must 1st save that record to the Server; otherwise, User A will get the current data of that record from Server, not the modified data.] On the other hand, in order to Import *Into* File 2, User A must have Write Access to the target records in File 2. If User A does not have Write Access for any reason, including the fact that the record is Locked from Write Access because some User (including User A) has the record Opened in File 2, then the modification of that record will not happen and an error is returned. [Error 729 - Errors occurred during import; records could not be imported]. We need to make the distinction between the process of importing records from File 1 that will create (add) *new* records in File 2 and the process of *updating* existing records in File 2 by importing data from records (the Found Set) in File 1. Adding *new* records requires the User to be able to Create (and Write) to the new records - and no User can have these records locked since they don't exist. Updating *existing* records requires that the User has Write Access to the target records - and some User could have some of these target records locked, preventing Write Access. In your situation, User A is updating records in File 2 with data from File 1, if I understand you correctly. If User B is modifying records in File 1 (the source file for User A), then User A should be OK. On the other hand, if User B is modifying records in File 2 (the target file for User A) and one of the records being modified by User B is also a target record for User A, then User A's update import will not modify that target record and an error will be generated that can be trapped by a script or shown to the User if a manual import is being performed. === One more thing: how are you determining that some record isn't being "imported" (I believe you mean "updated")? You mentioned 131 records in File 1 updating only 130 records in File 2. However, if (and that may be a big IF) there are two records in the 131 with a duplicate (matching) key, only 130 records will be updated in File 2; that is, only 130 records will be in the Found Set in File 2 following the (update) Import since 2 records in File 1 will both update the same record in File 2. Just thought that may be tripping you up as well ... maybe not. Hope this helps, Jason L. DeLooze On 7/2/11 at 3:03 PM +0200, Peter Buchanan wrote: > Hi Steve > >>So on the other user's computer, you opened FileA, went to some random > record, and placed the cursor in a random field? You didn't change >the data > in that field? > > I did create a blank space in the field - so the record is open and being > edited, and has not been committed. Just browsing the record does not stop > the import - I tested that also. > > >>Can I suggest you try exactly the same thing but (a) do a manual import and > (b) do a straight import of records (with no update options). >>I believe that will work and will give you confidence that Filemaker's > import routine isn't broken... > > Good idea for Monday - I do a lot of scripted imports, so I would like to > know what the problem is and how to sort it.... > > >>In no case would you expect an imported record to both create a new record > and update fields in an existing record, so I don't quite >understand this > statement. > > What I meant here is, if there are 131 records in found set in FileA, then > only 130 records are created (imported) into FileB. The 131st record (being > the open record in FileA, not the last record in FileA) is not created at > all, that is, it does not create a record with some fields blank or partly > updated. Also there is no match field in the two files, I manually find a > set of records in FileA, go to FileB and run a scripted import, with minor > updating based on local fields. > > >>There are many ways that locking can occur. For example, clicking in a > portal row will, I think, lock all records in the portal. >>So is it possible that the record you are expecting to be updated is > somehow locked/uncommitted? > > Oh...yes, these records in FileA are accessed via a portal in FileC. The > user in FileC will choose a record from the portal and import it into FileC, > and write a value back into FileA. I suppose it is possible that two users > (in Files B and C) are trying to import the same record at the same time > from FileA. Unlikely, but possible, and I suppose that the portal viewed in > FileC (with its updated value) will keep the FileA record open until user > closes the parent record in FileC. This could be the problem. But how to > track this and prevent a missing record in FileA? > > Appreciate the ideas and guidance on this > > Rgds > Peter > > > > -----Original Message----- > From: FileMaker Pro Discussions [mailto:[email protected]] On > Behalf Of Steve Cassidy > Sent: 02 July 2011 14:41 > To: [email protected] > Subject: Re: Import / locked record > > Hi Peter > > This sounds rather unusual. I still have a feeling there's something else > going on... > >> 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. > > So on the other user's computer, you opened FileA, went to some random > record, and placed the cursor in a random field? You didn't change the data > in that field? > >> Went to FileB and imported the current found set from FileA. Error capture >> is on in FileB. No errors reported. > > Since you are using error capture, you must be doing this in a script. And > presumably, as you have explained before, you are using the Update options > in the import script step? > > Can I suggest you try exactly the same thing but (a) do a manual import and > (b) do a straight import of records (with no update options). > > I believe that will work and will give you confidence that Filemaker's > import routine isn't broken... > >> 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. > > In no case would you expect an imported record to both create a new record > and update fields in an existing record, so I don't quite understand this > statement. > > But it does set another train of thought in mind... > > If the record that's failing to import matches a record in FileB, then you > would expect the record in FileB to be updated. However, if that record in > FileB is open (locked) on another user's computer (or perhaps even in > another window on your computer), I would assume that the update would > fail. > > There are many ways that locking can occur. For example, clicking in a > portal row will, I think, lock all records in the portal. > > So is it possible that the record you are expecting to be updated is somehow > locked/uncommitted? > >> >> 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. > > As I say, try running the import manually. You will then get the import > summary message, which might help your diagnosis. > > HTH > > Steve
