A successful manual import had me looking again at the script. At the very
beginning of the import process, a variable could not be inserted into the
locked record, which was then in fact being imported into FileB, but could
not been "seen" from its new parent record, because the match field was
blank.
Thanks to all the input - I now again have confidence in Filemaker's import
function, but my scripting needs some improvement....
-----Original Message-----
From: FileMaker Pro Discussions [mailto:[log in to unmask]] On
Behalf Of Jason DeLooze
Sent: 03 July 2011 22:44
To: [log in to unmask]
Subject: Re: Import / locked record
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
|
