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
