There are many threads with the same problem. I would like to do this too. The answer appears to simply be....you can't. Maybe someone will come up with a work around.
Vicky Nuttall and STEVE MARTINO:
Thank you for your posts.
At this time, FileMaker files cannot be copied to Dropbox on an iOS device. You can either email (which is not an option) or use iiTunes and copy the file to host machine.
Another possible workaround is to consider syncing. That is, when the iOS device gets a network connection, update the data on the host machine. For more information, see the FileMaker Sync Guide at:
In addition, there are some third-party vendors that have programmed a sync solution. For example, GoZync and 360Works MirrorSync.
Wow, that was not the answer that I wanted to hear. (!)
Is there any way to get a FileMaker Go database out of FMGo on the iPad itself, so that it could maybe be transferred some other way?
Or, is it possible for me to script an ftp transfer to my ftp site, and run the script from within the database when it's in FileMaker Go? I could see this as a possible solution..... thoughts? ideas?
No. Filemaker go is required for your database to run on ios device. There is an filemaker go app maker - profile generator, which allows you to lanch your app from an icon on the home screen.
iTunes is the best way to get your app on the device. You could create a method that uploads the data from the ipad when the device has coverage then blanks the data from the ipad after the data is upload. Basically eveyone would enter data on the ipad locally and at the end of the day they would upload to the main database (server). Or as mentioned above use a 3th party program.
ALTERNATIVELY you can share the DBs from your computers (FMPA or FMS only???), then open then from the "server". while on the road with your iPad. That way any changes you make are reflected in the orig DB.
2) you're using celluar data
3) involves some setup
4) you need to leave computer on with desired DB's open.
On the otherhand, this sometimes beats the complexties and reliability of syncing methods.
Suggest you add your wish to that of countless others...
Vicki already states they are already using a server, but they need another method when there is no internet connection (No celluar). Yes, there are still areas that doesn't have celluar coverage. So the only other choice is to sync. The problem with using Dropbox is several people openning the databases at the same time, which could corrupt the database. Again, the question was what to do when you have no internet.
Hi, folks. I'd almost forgotten that I did this post originally. Thank you all for your comments. Also thanks to TSGal for the suggestion to go read the document on synching. It was extremely helpful (exhaustive, even). Without it, I couldn't have come up with the solution. I urge anyone else to read it, as well.
Here's what I wound up doing: In addition to the online database which contains the original data that needs to be deployed on the iPad, there is also a separate and empty "shell" of a database that sits on a user's desktop. This is a file that does no lookups, it is just set up with fields that are set to receive data dumped from the online database. I'll call it the "shell" file.
The user finds the records in the online database, then runs a script which opens the shell and run a script in the shell to import the found set of records from the online file. That same script then initiates a Save As Copy function which the user then completes manually--the users need each saved file to have a username and a date to identify it going out and coming back. The user checks the checkbox to have the script then attach the saved file to an email, which kicks off the local email program, creates an email, and attaches the database file. This is then sent to the technician using the iPad. FileMaker Go is already set up on each technician's iPad.
The technician checks email, downloads the file to the iPad, and then opens it in FileMaker Go. This loads it onto the iPad as a local device, so the tech can work in areas where there is no internet access and still fill out the fields. When he returns at the end of the workday, or as soon as internet connection is reestablished, he kicks off a script in the shell file that saves a copy of the file and attaches it to an outgoing email. The tech sends it back to the office.
At the office the email attachment is saved to the local hard drive. Then the user access a script in the online file which imports from the saved file. The import is done into a table specifically set up for this purpose, not into the table that is used for the original data. The script which does the import also finds each pair of records in the two tables using the key data, and sets the specific fields in the regular-use table to the data in the corresponding fields in the import table. It also sets synch flag fields and date/time entries.
We opted for emailing the standalone files back and forth because, after I read the synching document, I realized that the databases going back and forth would be small enough to actually make it through an email process, plus I felt it was safer in our situation to give the office workers an "audit trail" of data going out and coming back in via the standalone files that are sent/received.
Also, I felt that putting the burden of completing the send process from either source onto an email process was better than having the synch go directly from the shell on the iPad, because there seems to be many possibilities for the direct upload to fail (user forgets and hibernates FileMaker Go, etc.)
Hope this helps other people.