Thanks for your reply weaverd.
That is along the sames lines but the sample I pointed to in my original post is more complete. The article you referenced at the bottom says to stay tuned for more, indicating more on the subject but that appears to have not materialized in the past year.
Could you explain more details of what you want to achieve? For example:
- do you solemnly swear that the remote ('disconnected') user will never do any data entry updating on the copy of the file?
- how out-of-date can the copied file be before it is useless?
- why do you think peer-to-peer is unsafe?
- why do you need a dedicated server (how many simultaneous users do you need to accommodate)?
- which version of FM are you using?
Could you explain more details of what you want to achieve?
Thanks for your response.
I basically wish to replicate the functionality from the link in my original post.
Answers to questions.
1. No, that's the point. I'm the only user, and can't, despite what my customers wish, be in 2 places at once. But looking at the link I posted I don't think it matters. It seems like the main file stays in Dropbox and any user reads/writes from/to it. So record locking wouldn't be an issue unless I left my desktop on with an open/uncommitted record.
2. Out of date...Based on above, I don't think it matters with the above mentioned demo. Right now I delete the file on the IOS, and download an updated copy.
3. Peer-to-peer, documented/recommended as not the best way to host/share a file. Great when developing a solution for checking layouts and functions on an IOS device without having to shuffle the file back and forth.
4. Trying to avoid the expense of server for a one man band. Just trying to come up with something between moving files from desktop to IOS, and back. Working on the road and having updated data is pretty convenient. It allows me the opportunity to do more things paperless on the road, and less paperwork back at the office. But shuffling, moving, deleting, updating back and forth gets annoying.
5. FM Pro Adv 12, currently doing a complete re-build with 15.
I did look at the sync plug-ins before, 3 of the more popular require server.
If you are the only user of the database you can use Dropbox, but I would not recommend it. It is a big risk that your database will end up being corrupt. You can of course put on Dropbox and then put down on your computer/phone when you work on it and put it back up again, but that would be to much work.
I would find a FileMaker Partner that could help you setup a FileMaker Team License for you and host your database
If you are the only user, and you will never edit records in the 'remote' copy, then you could have the live file save a backup of itself to your Dropbox folder every night. Note: do not run the live file from the Dropbox folder.
Next morning that backup file will then be available on your iOS device (courtesy of Dropbox) and you can then copy it to your working folder on the iOS and work away. Next day just replace that 'working file' with the latest Dropbox version, ad nauseum.
The vast majority of our customers use peer-to-peer and it is rock solid.
You don't need a server to do the above (but what you are asking for is very limited, so the solution matches that requirement).
If you are commonly using the remote file when you actually have internet access (wifi or 4G) then you don't need to do any of that copying; you can access the live file directly, and then you could create and edit records while on the road. In fact, if you have a driving need (no pun intended) to edit the live file then it may be that you can wait until you have access and then do that occasional bit of work on the live file, while using the 'copy' only for browsing, and/or while unconnected to the web.
1 of 1 people found this helpful
Why not just try it
If your file is not enormous, you don't need to synch with exported records. Just grab the entire file
With Dropbox, it's the local file that runs. When you quit FileMaker, and the file is closed, Dropbox makes a copy, that is then available remotely
> I'm the only user
I would be very careful about actually opening and using the Dropbox file. My understanding is that Dropbox will sync its version of the file every time the file is saved (ie: modified). As Filemaker will be auto-saving every record edit then Dropbox will copy the (opened, live) file to sync it across devices. Copying an open Filemaker file is a big no-no. Perhaps it would be safe with a guaranteed one-user set up, but I don;t see the point of risking it. (What happens when the user edits and commits data in a record, Dropbox starts to sync, then before it has finished, the user starts to edit the record again?)
That is why I was suggesting to set a script OnTimer to save a copy of the file to Dropbox every night, then to move that Dropbox copy before using it on the iOS.
1 of 1 people found this helpful
No. Try it
Dropbox does not copy the file until you quit FileMaker, and the file is closed
Dropbox could work here, because there is only one user
> Dropbox will sync its version of the file every time the file is saved (ie: modified)
Thanks to all the responders. I am familiar with many of the techniques described, and the caveats. But to bring the topic back on point, I'm specifically looking for comments specifically to. and to reproduce, the technique posed in my original post, found here:
I am familiar with all the ways currently available.
This above mentioned technique seems to avoid the many pitfalls mentioned above because it appears both (all) users are using the database from the same file. The only issue being something as standard as record locking.
I just found the above technique and video interesting, and was looking for a sample file/reproduction. If anyone wants to take a crack at it as a paying job, PM me.
The video of the blog shows that what is being synchronized is not the filemaker file but rather its exported (and imported) data in simple text format. It's not a bad idea but it would not be 'very simple' to implement and require extensive scripting.
I tried opening a Filemaker file directly from my Dropbox, and I was surprised to see that it did not update on record commit. However it did update when 'Flush cache' was instigated (without closing the file or quitting Filemaker), so depending on the design and use of the file it may still have the potential for corruption.
But in the very restricted use the OP has for it it would look like a solution.
If you are the only user, why would you want to bother with one of the synchronising plug-ins? if your remote location has access to the web then just log in to your live file and 'all users' are indeed using the 'same file'. If you do not have regular remote web access then the techniques suggested will all work for you.
We wrote a Field Engineer Support program for engineers who would have no web connection on site. They needed to have the details of the job they were working on, the ability to raise an invoice while on-site (and capture the customer's signature), as well as access to all the previous service reports for the site (which may of course have been raised by other engineers). When they got back to an area of 3G reception they would synchronise all of the job details they had entered while off-line, they would be synchronised to all the other engineers, the invoice would be sent back to HQ, and they would their schedule would be updated with any new or changed jobs for them.
I don't believe you would ever want to pay for such a synchronisation - it was a mammoth task. If Todd Geist's synchronising had been around I would have happily used it.
After watching the video it looks like the data is exported from FileMaker app to external file. External file is transferred to dropbox via dropbox api. Then the data is imported from the dropbox file to FileMaker app. For a simple app this is could quite well working solution for data sync. Using something like UUID as primary key value, data created in another app instance (Go and FMP are the two instances) is not conflicting when text-datafile is imported. Comparing records to their update timestamps will add some complexity to it if more advanced synchronization is needed.