The software is out of date and is not compatible as is with FMGo 12 and above. FMP12 and above files have a fmp12 file extension where as fmp7 - 11 have fp7 file extension. FMP12 and above has to covert the file to FMP12. You would have to have old versions of FMP, FMGo and ios for this to work as it. The program may can be updated to work but scripts will have to be modified. FMGo 12 - FMGo 14 and above requires a FMP12 file.
If you're using FileMaker Go 13/14 make sure you're using the most recent version of this technique:
it contains some changes about the length of the pause and duration of the OnTimer script.
Yes, that link was for the original article that was for FM11; I am using the updated version of the demo that they provided that is supposed to run under 13 (at least).
I was wondering about the timing of the on-timer script, but the comment near that step says that the amount of time doesn't really matter. But I haven't had a chance to mess with it yet.
I went by the link you provided. I have not used it before, but look interesting. I downloaded the newer version but I have not had time to look at it. I will take a look at it hopefully later today.
I just tried the new version and it worked as described.
Download the mobile file to my iPhone (version 1), went to a computer export the file out of the container field which is placed on the desktop, and enter 2 and the new version number, then inserted new file into container field, went back to iPhone and the file updated to the new version 2.
Well, I tried the same thing - going back to the vanilla demo file. And that also worked for me. I must have messed something up in the implementation. I will have to excavate to see what I can find.
Well, no dice so far.
I have tried a different server, one that doesn't have a PW protected list of files, and that didn't work. Just to be sure, I tried the vanilla files on the client's server and that DID work. I also tried deploying the vanilla 'mobile' file from the client's solution, and that also DID work.
I then copied all of the original scripts in from the vanilla file to my file, only make some minor changes to try and make sure I hadn't messed up anything there. (I do have to make some changes as the server name is different, I had a different file name for a while, etc.) That wasn't getting me success, so I even went back to using the vanilla filename.
Then I thought that the external data sources in our deployable file might be causing problems; there was some discussion in the documentation for the sync model (which this file is) about external data sources preventing the file from closing the hosted file, etc. So I removed the EDSs that where there and tried again: it failed.
I then tested out file size as a possible contributor; that didn't change anything and stuff still failed on my file, but it DID work OK on the vanilla file even after adding some container data to make it large.
I am going to try a clone and recovered file next; I'm still wondering if the EDSs (even though I deleted them) might still have some hooks in the file. (This didn't work.)
After that, short of just starting from a completely new file and building it up, I'm not sure what else to try. Guess I could try the external file approach mentioned above. I.e. have a 2nd file that is exported from the current file and then does the updating of the current file.
I don't understand your statement.
"Guess I could try the external file approach mentioned above. I.e. have a 2nd file that is exported from the current file and then does the updating of the current file."
There is only one method mentioned and it consist of three files. One file on the server (GoConnect) which contains the updated mobile file in a container field (Mobile2.0) and the mobile file that is on the device (Mobile1.0).
Probably because my comments were out of context.
I was thinking about a solution posted in another thread that I started on this problem in another forum.
The idea is that the deployed/mobile file exports a 3rd file from itself (spawn, say), and it is this new file that closes the mobile file and then calls the host file to export and open a new copy of the mobile file to the device. There were a couple of folks in that thread that recommended such a solution.
But I am curious, and frustrated, why the original technique doesn't seem to be working in my file but works fine in the demo. <sigh>
The original technique will work. The technique you describe does not make sense because the purpose is to move updates from the server to the device, not from a local file to another local file. If it will work from one local file to another local then it will work from a network file to a local file.
I have tried to explain the direction in a different manner just incase you missed something.
There will be three files used.
Goconnect is install on the server.
Goconnect contains one file called mobile 1.0.
You connect to the server from the ios device. You will click download to device. This step will download the mobile 1.0 file out of the container on to the ios device.
You will go back to the computer. You will export mobile1.0 on to the desktop. mobile 1.0 is the file that is being used on the desktop.
You open file and change the version number 2.0 which is a simulation of data being enter into a file mobile 1.0.
You then import mobile 2.0 into the container field within Goconnect. This will overwrite 1.0 in the container field.
Now you have two updated files 1 is mobile1 has been updated to mobile2 and Goconnect has updated data in the container which now contains mobile2. You then go back to your ios device open mobile1 and click update this file. 2.0 will be downloaded and 1.0 will close .
If you still have issue you will have to give more details on how it is failing.
I know that the original technique WILL work, in certain cases - I have gotten the demo files to work a couple of different times. But for whatever reason it is not working for me when I implement it in my file. When I try it from my files I am always getting a 'file locked or is in use' error when it tries to export the updated deployable file from the Server to the device. This implies, to me, that the device's file isn't being closed completely for some reason. I don't know why.
The other technique I mentioned will also work. A number of people in the other thread (Update-in-place on iOs - FileMaker Go for iPhone & iPad - FMForums.com) say they have employed this technique. They mention that this is the technique used in the EasyDeploy project, an open source demo by Tim Dietricht. It isn't updating from a local-to-local file as you described. There is just a 3rd file in the update process instead of 2:
New update posted to the server ('HostA'):
* a new file, 'deviceB' is inserted into a container in 'HostA'
Deployed file checks for updates:
* 'deviceA' checks 'HostA' for updates
* If a new file exists, 'deviceA' exports 'updaterA' file
'updaterA' then does the work
* closes 'deviceA' file (in theory this works as expected)
* connects to 'HostA'
* exports the 'deviceB' file, from 'HostA', to the local device
* opening 'deviceB'
Now I can't say that I have actually implemented this yet, but I am familiar with the theory. The original one-click-update-in-place technique sounds great, if it would work reliably. But there are apparently some gotchas with it that make it not work in my situation. If I knew what those gotchas were then perhaps I could code around them, but I can't find the cause.
Now, what I HAVEN'T tried (and actually won't be possible for this client) is to leave the hosted 'updater' file separate from the client's regular hosted file. That is, the 'GoConnect' updater file will be hosted alongside the main 'HostA' file as described in my process above. Then the updating process would contact that 2nd hosted file for updates instead of the primary hosted file. My current implementation has been to move the scripts/fields into my own files (one deployed/local/device file and one hosted file - these 2 files standing in place of the 'mobile' and 'goconnect' files of the demo) and try to run this process from inside there.
I would think that it shouldn't matter: the local device file doesn't have references to the hosted file - the hosted file is being opened via FMP URL, not by a direct reference from the local file. So it doesn't seem like there should be anything tying the local file to the hosted file, and thus the local file should be closed when asked.
But, we can't just add another hosted file in this case - the client is using a shared-hosting service and only gets 1 file on the server. They don't want to pony up to have more files, I wouldn't think, not just for this one technique. But I haven't inquired. I would also have to demonstrate that the separate-hosted-files would even work. I will see if I have time today to test that.
The one-click update mention on the other forum is the same as on this forum. The one click update uses 3 files not 2 files. The first file is GoConnect. The second file is mobile 2.0 which is in the container field in GoConnect and gets download to replace mobile 1 on the device. The third file is mobile 1 on the device. They provide 2 files but you update mobile1 to mobile2 and then insert into container, which is the 3rd file in the process.
One click update does not update the data in the file (It over writes the database mobile 1) and is not a GoSync or EasySync solution. These are different products. There really is not much use for the one click updater because of drop box and those type products. One click was designed when FMGo was first released and you could only transfer files to the device by iTunes or Email. One click made it easier to get a new update version of your database to the user.
One Click is not a syncing program. It does not sync your data. It overwrite the database on the device with a newer version.
Yes, the threads are about the same 'One-Click' demo because I started both threads at the same time.
Yes, there are technically 3 different files in the One-Click process but I wasn't considering the 'updated version' to be a separate file; it is just a version of the already deployed file. In the EasyDeploy workflow there would then be 4 files: 3 unique and distinct files, plus one 'modified' file which is a copy of already deployed file.
I realize that it isn't syncing anything. Yes, it will overwrite all existing data in the deployed file.
One-Click (or something similar) deployment still seems to me to be a highly viable technique for deploying files. You don't have to leave FileMaker, you don't have to leave the solution that you created, in order to do updates. It could conceivably be automated so the user doesn't even have to check for updates, they would just get a dialog if there is one.
I just wish I knew why it wasn't working for my files.
Easysync is a different product, data is being synced, so there would be a need of additional file to handle the syncing of the data between the files. I have no idea what you have and have not done with your files. There is nothing special with the samples so I'm sure that something has just been over looked. You will have to post a sample of your files and or post scripts that you are using.