Jason,

Thanks for the contribution.

As suggested by Steve, some more testing tomorrow in the network
environment, including a manual import when UserB is editing a record and
when UserC has a record open in a portal, plus looking for error code 729,
might reveal what is going on. Can't help thinking that I have missed
something obvious....

Just to clarify further :

Records (the found set) are being found by date range search in FileA, by
UserA. 

UserA then moves to FileB, and runs a script to import the found set into
FileB. 

UserA has full rights to both files. And in this case, it is two files, not
between two tables in one file.

Records in FileB are not being updated, but are being created by import of
the found set (new records). Some fields in the newly created records are
being updated with auto-enter calc values, but not by reference to FileA. So
I have excluded any matching fields as being part of the problem.

If the found set comprises 131 records, then only 130 new records are
created by the scripted import. During testing, when I checked which record
was missing, it was the record opened and under edit by UserB. It was not
the first or last record, which was what I first suspected. 

As you point out, I would expect the existing server copy of the record to
be imported, irrespective of whether or not the record was open on a
workstation.

Regards
Peter



-----Original Message-----
From: FileMaker Pro Discussions [mailto:[log in to unmask]] On
Behalf Of Jason DeLooze
Sent: 03 July 2011 01:23
To: [log in to unmask]
Subject: Re: Import / locked record

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:[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