Save a Copy isn't supported for hosted databases. If you want to have an offline version of the database, your best bet is to implement a mobile version and a syncing solution. There are commercial syncing tools available (GoZync from SeedCode, MirrorSync from 360Works, or EasySync - which is open source). You can also roll your own, if you're so inclined.
Another option would be simply to copy the database from a backup down to the iPad, then import the records that have been changed back to the hosted solution manually. This is risky, since you can easily screw up the import, and you have to be careful about multi-user situations. If two people make offline changes to the same record, who wins? What if one user deletes a record, but the other needs it?
As you might see, synchronizing multiple copies of a data system isn't a trivial exercise. You will need to think through your business rules and all the various scenarios and make sure you understand what can and will happen. Nevertheless, given that careful preparation, syncing solutions work quite well.
thanks for the response. The database on the ipad will be completely standalone and just issuing PDF's back to base via emails. It was simply the best way to get the version onto the ipad that we were looking for. However we have now linked a version to a googledocs page, and a link to that allows a download, followed by 'open in filemaker go', which seems a simple solution , after which it opens directly in filemaker go.
How are you getting the data into the GoogleDocs version?
We are copying the whole database into the googledocs page, just using it as storage. Then linking to it via a web url for download.
Another option you could use is to store the file in a container field and use export field contents to bring the file to the iPad. This option would avoid the Open in option that you get with Google.
Okay. Wanted to determine if there might be a risk of file corruption. What you want is for users to copy the file down, not try to open it on the remote drive. Otherwise, the original file can be damaged or others locked out when they try to access it.
rgordon's idea of using a container field is actually quite good for this use case. It avoids the GoogleDocs issue entirely.