7 Replies Latest reply on May 19, 2013 12:07 PM by vickyn

    Getting a FMGo database off iPad and to Dropbox



      Getting a FMGo database off iPad and to Dropbox


           Hello, I have a client with an online database and I'm creating a a standalone database that's a mirror of the online one. Their workers could use the online database to enter data on the jobsite when the internet connection is good, but it turns out that the connection is too slow, not consistent, etc., so they will need to use the standalone database (downloaded to their iPads) to enter when the connection isn't good (inside malls, etc., where the work is being done).

           The users are taking photos of the work done with the iPads and entering these into container fields in the database, so the resulting file is going to be too large to email through usual email servers.  Multiple databases will be coming in from the various workers in this scenario.

           I want to explore having the workers send from the iPad to Dropbox so that the main office can import the records into the online database. The solution to getting the data back to the office needs to be simple.

           But I'm having a brain fart and can't figure out how to get a database from the iPad to Dropbox. Do I need to set up an email that is specific only to Dropbox so that it doesn't try to go from the iPad through any normal (limiting) email servers? In testing, that is what's happening since the email I used is one that goes through my website, and also is linked to Dropbox.

           I have to confess that I'm a little flummoxed by Dropbox. So maybe there is something I just don;t "get".  Any ideas?



        • 1. Re: Getting a FMGo database off iPad and to Dropbox

               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.

          • 2. Re: Getting a FMGo database off iPad and to Dropbox

                 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.

                 FileMaker, Inc.

            • 3. Re: Getting a FMGo database off iPad and to Dropbox

                   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?


              • 4. Re: Getting a FMGo database off iPad and to Dropbox

                     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.


                • 5. Re: Getting a FMGo database off iPad and to Dropbox


                       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.

                       The downside:
                       1) slow(er),
                       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...

                  • 6. Re: Getting a FMGo database off iPad and to Dropbox

                         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.

                    • 7. Re: Getting a FMGo database off iPad and to Dropbox

                           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.