Issue Importing between tables/layouts

[Stargazer]

Hi Everyone,

 

I'm having an issue with moving records between tables within my file. I've already implemented this successfully in one instance, setting the source by performing a find within one layout then setting up an import to another layout from the same file that's being worked in.

 

However when I try to do this using the same method between another two layouts I'm struggling to get the source to set up correctly as filemaker appears to keep setting the source as the same as my desired target layout. Any ideas as to what might be causing this?

 

I don't know whether it's relevent but the layout I'm moving the records from was duplicated from the layout that I'm moving the records to (which is appearing as the source as well as the target). However I have changed all of the fields on it to the ones appropriate to the new table as well as linking the layout to the new table as well. There's nothing I can see anywhere that would indicate that the layout is in any way still associated with the table which is behind the layout that I originally duplicated. Could this be the problem? Would I be better starting from scratch?

 

If I turn off the perform without dialog option I can then manually select the source without issue however this is unsatisfactory for the final solution.

[comment]

There's very little detail here. Offhand, I would delete the Import Records script step and create a new one. If that doesn't help, print out your script and post it here.

[Stargazer]

Enter Browse Mode

#Dialogue to confirm that the user wants to move the current item

Show Custom Dialogue["Confirm Item is Correct" ; "Are you sure the item's information is accurate?"]

#If statement checks the response to the dialoge then proceeds with script

If[Get ( LastMessageChoice ) = 2]

    #Freeze window to prevent UI from jumping around

    Freeze Window

    #Make the current record the only member of a found set

    Set Variable [$ID; Value:Suspect::Internal Designation]

    Perform Find [Restore]

    #Go to the Equipment layout and import the found set thats just been created

    Go to Layout ["Equipment"(Equipment)]

    Set Variable [$filepath; Value: Get ( FilePath )]

    Import Records ["$filepath"; Add; Windows ANSI]

 

That's the relevant part of the script. The basic premise is moving an item from the "Suspect" table to the "Equipment" table. The "Internal Designation" which is set as a variable is the primary key of the record.

 

Having deleted the import step and redefining it. The script is no longer was sourcing from the "Equipment" table, however it's now sourcing from a different table rather than the desired "Suspect" table.

 

Thanks for the help

 

Edit: Just to clarify, the find that is performed is simply for the record which matches the $ID variable to make the desired record for transfer the sole record of a found set.

[eos]

Edit: Just to clarify, the find that is performed is simply for the record which matches the $ID variable to make the desired record for transfer the sole record of a found set.

 

Or try 

#Make the current record the only member of a found set
Find Matching Records [ Replace; Suspect::Internal Designation ]
#Go to the Equipment layout and import the found set thats just been created

[Stargazer]

Thanks eos, that's a neater way of defining the found set, however my import unfortunately still doesn't work. I haven't been having issues with defining the found set the issue seems to be simply having the correct source for the import record step.

[comment]

I suggest you replace the $filepath in the Import Records [] script step with an actual file reference to your file. This will enable you to open the 'Import Field Mapping' window with the source file's tables and fields present. Once you select them, the script step should remember them.

[Stargazer]

Your sentence about the script step remembering the source gave me an idea. I performed the script with the dialog on for the import step then manually selected the correct source and proceeded with the import. It would now appear that the problem is solved as the script now "remembers" the source.

 

It strikes me as slightly odd that this is the way the script behaves however, as what's the point of creating a found set to act as the source if filemaker still has to be pointed in that direction anyway? Can anyone explain this behaviour or is it only something which has happened in my script and is something unusual?

 

Thank you for your help!

[comment]

I am not sure I fully follow your description. One thing is fairly certain, though: when your Import Records script step uses a variable to determine the source file, Filemaker does not open the source file while the script step is being set up (and why should it, when it's variable?). So you cannot, at this point, select the source file's table/fields.

[Stargazer]

I understand that part, I'll try to rephrase.

 

When you create the found set in the script, my understanding is that this is so that when filemaker goes to import from the file it imports the found set you have just defined, rather than other records from the file. You are essentially telling it what should be imported (although it won't know this until the import step I know)

 

If this is the case I don't understand why it would need pointing to the source again at the import step as what's being imported has been defined by the found set previously no?

 

If the answer is "because that's just the way you have to do it" then that's fine I'm just trying to see if there's a reason as to why the script has behaved this way.

[comment]

When you create the found set in the script, my understanding is that this is so that when filemaker goes to import from the file it imports the found set you have just defined,

 

That may be your understanding (since you understand the overall concept of your script), but that's certainly not the understanding of the application that merely executes the script steps in sequence. There is no good reason to presume that creating a found set just before importing is done in order to import that specific found set. For example, you could be preparing the found set in the target table (for importing matching records). Or you could be just tidying up something before moving to the import, with no connection whatsoever between the two actions, other than that they need to be run at the same time.

 

IOW, each script step as an independent unit and Filemaker does not try to infer anything from the way they are combined in a script.

[Stargazer]

That may be your understanding (since you understand the overall concept of your script), but that's certainly not the understanding of the application that merely executes the script steps in sequence. There is no good reason to presume that creating a found set just before importing is done in order to import that specific found set. For example, you could be preparing the found set in the target table (for importing matching records). Or you could be just tidying up something before moving to the import, with no connection whatsoever between the two actions, other than that they need to be run at the same time.

 

IOW, each script step as an independent unit and Filemaker does not try to infer anything from the way they are combined in a script.

 

Thank you for your patience Comment, that makes it clearer and I can see now why that's the case. I still think the Import script step is a bit clunky (basically why can't you just define the source within the step as you write the script rather than upon execute) but that might just be me.. I will bear this in mind in future

[comment]

basically why can't you just define the source within the step as you write the script

 

You can. That's exactly what I suggested in post #6.

[Stargazer]

d'oh yep sorry completely forgot that.. Thanks Comment