FMPRO-L Archives

July 2011, Week 1

FMPRO-L@LISTSERV.DARTMOUTH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steve Cassidy <[log in to unmask]>
Reply To:
FileMaker Pro Discussions <[log in to unmask]>
Date:
Sat, 2 Jul 2011 13:41:00 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (45 lines)
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

ATOM RSS1 RSS2