Peter,

(See comments within your response)

On 7/3/11 at 5:02 PM +0200, Peter Buchanan wrote:

> 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....

I would suggest that you capture *any* error due to the Import (not just the 729 error), then handle the various error codes according to your design.  For example,

Set Error Capture[ On ]
Import Records[ ... ]
If[ Let( $lastError = Get( LastError ) ; $lastError <> 0 ) ]
   If[ $lastError = 729 ]
    ...
   Else If[ $lastError = 1 ]
    ...
   End If
End If



> 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.

If the Import from File A to File B is using the "Add new records" option, then I would expect that all records in the Found Set of File A would be created in File B, unless there was something that prevented the creation of some records.  There are several things which could, in general, prevent a User from being able to create records.  However, in your situation, since the User is able to create some records but not others via an import, many of these ways do not apply. But one that does apply is "validation", and in particular, "record validation" as compared to "field validation".

I have written extensively some time ago on the subject of validation and the different aspects of field vs record validation.  Briefly, depending on which validation option used (and when), a failed field validation can have 1 of 3 results: (1) the record is imported (created) and no error is returned; (2) the record is imported (created), the field failing validation is left empty, and an error is returned; or (3) no record is imported (created).  This 3rd result seems to apply in your situation.

Result #3 (no record is created during the import process) requires two things: (1) Always Validate, and (2) a record-level validation.  The key item is the "Always Validate" option.  I would 1st examine the field definitions in File B, looking for any that says "Validate Always".  Then I would examine each of the "Always Validate" validations to see which ones are "record-level" validations.  If there are any, that could be the reason the record is not created during the Import process.

Regards,
Jason L. DeLooze