Importing data from another Filemaker Database - Multiple Tables

[lukecockell]

I'm trying to move records between two Filemaker databases. One of the databases "Target" will be hosted on the server, one "Source" will be used on an iPad through Filemaker Go, however at the moment, they are both running locally on my workstation (from what I understand, I can only import from another local file using Filemaker Go, and Filemakers knowledge base article reflects this fact).

 

I'm trying to migrate data from two individual tables, in both databases both called Table1 and Table2. On the source file, I've got a script that will go to the layout of table1, run a script (called import1) on the target database, import the table1 into table1. My script then changes the layout to table2 (this has previously worked for me), and runs import2 on the target database. While I expect this to set the source table to table2 and the destination as table2, it actually selects the source as table1. I cannot get this to permanently change. As it's running on Filemaker Go, I cannot use the dialogue to change it when required.

 

Can anyone help shed some light onto this? The "import" will only ever add new records to the target, and there is only ever 1 way sync, so in theory it should be fairly straight forward. If anyone has any better suggestions on how to implement this, I'm all ears.

 

I've managed to replicate the problem on two sample files, which I've attached; should this problem be fixed, it will be implemented into a much larger database that's currently under construction

 

https://www.dropbox.com/sh/jwb4mw6sr29ga06/GFVRwovvn1

 

Can anyone help?

 

Many thanks,

 

Luke

[Manjit Behera]

Hi Luke,

 

Do you want to migrate all data from your Source file to Target for all tables?

Do you want to just transfer data or want to update (existing data) + Import (new data) ?

 

Please reply to my questions, so that I can able to help you.

 

 

Thanks

[lukecockell]

Thanks for your reply.

 

At the moment it works in the way I'd like it to, in that it only imports the data that's currently valid for the search, but I can have a "selected" field if necessary.

 

I'll never be updating data just adding new rows.

 

Thanks,

[lukecockell]

Is anyone able to help at all?

 

After investigating this further, I'm able to find that if I select "All Available Files" in the script step, it performs as required on my desktop, but when I select "Filemaker Pro", it doesn't perform correctly. Unfortunetly, the "All Available Files" step doesn't appear to be compatible with Filemaker Go for the iPad, and therefore, I'm restricted to "Filemaker Pro" file types.

 

Help!

 

Thanks,

[Wim Decorte]

Is anyone able to help at all?

 

 

 

 

Have some patience.  Nobody is getting paid to do this and it IS the holidays...

 

In your script: the fact that you change context to the Table2 sets the target table but does NOT automatically change the source.

In order to make it stick you need to set it once using a real hard coded file reference in the import script step and save your script.  Then when you remove it and save your script: if the dynamic file reference has an equivalent Table2 like the hard coded one that used originally, it will do the match.

[lukecockell]

Sorry, I'd come across in a bad way there! Not a good start for a new member!

 

Thanks for your suggestion so far, but it doesn't seem to work for me.

 

I've changed the dynamic association on the target database to a static address. I've saved the script, and set the dialogue to appear. When running it, it's still not showing the correct database as the source one. When I change it, and run the script again, it doesn't keep the association. When changing it back it doesn't show the correct one on the dialogue either.

 

I'm making these changes on the solution I'm putting together rather than the one I attached.

 

I managed to get it working elsewhere, in the way I want it to, but it would require a lot of redevelopment to rebuild what I've done already, so obviously, if I don't have to, I won't go down that route! I do need to understand where I'm going wrong though, because as I continue to develop, I cannot be in a position where I'm doing a test with an iOS device against the server version every time I make a change, as this will take a lot longer than I have available.