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:[log in to unmask]] On
Behalf Of Steve Cassidy
Sent: 02 July 2011 14:41
To: [log in to unmask]
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