DCA

I have a solution where users in the field add records in FM Go on their iPhones. That data is then synced to the server. No data needs to go back to the mobile device. I followed the instructions and named the TO's with the prefix ES_PUSH_ on both tables in both the hosted and mobile files. However, when I run it, it transfers all of the data on the server down to the mobile device. Is there something I've missed? Why is it pulling data when it should only push it? Marc

Good luck with that Douglas. If you do figure out the cause and an actual solution, please post it here. I'd certainly be interested, even though we've pretty much given up on FM EasySync for our solution. Marc

Tim, Considering I've lost close to $50K in other work while trying to sort this out, I'm reluctant to waste any more time trying to figure out the exact cause. I'll just wait and see if the problem occurs again during our final testing. Marc

My sync process is finally working. I managed to identify the cause of the problem and found a workaround. Unfortunately, I still haven’t found the cause or a solution, just a workaround. As I’ve always said when it comes to anything FileMaker related, where there’s a need, there’s a workaround. So, here’s my journey and I hope that if this ever rears its’ ugly head to anyone else, this post will help diagnose and solve the problem. Whenever I ran the sync process in my mobile file, it would always fail with an error 106 (Table missing). I had thoroughly checked every single TO and relationship in both files literally hundreds of times and everything was exactly as it should be. Eventually, I ran the script with the debug pull payload option switched on. If you’re ever tried that, you’ll know how painful it is. After hitting the enter key several thousand times (four times per record), it eventually stopped, allowing me to see the problem. The primary table in the process was using a TO named ES_Projects, however the script was showing it as ?[[bR]]ES_Projects. I have no idea what the ?[[bR]] prefix means or what caused it. At least I knew where the problem was occurring. I deleted the TO’s in both files and replaced them with new ones and even renamed them to ES_PROJ. I ran the sync script again and it failed yet again with a 106 error. The difference this time is that it had processed more records than the previous attempt. Working backwards through the list of TO’s and manually finding the number of records to be processed, I identified that the problem was with the next table after the projects one. I disabled the relationship in both files and renamed the TO’s and ran it again. The same problem occurred, this time with the next table. The conclusion I came to was that the sync process would get to a certain point and then fail. If I disabled the process at the fault, it would simply move the problem to the next table. I was able to identify the table name variable and put it onto the EasySync Payloads layout as a merge variable so I could at least see the faulty table name. Each and every time, the failure point included the same prefix of ?[[bR]]. After digging through the pull payload script, I found where the $table_name variable was set and added a variable after it which set $table_name to Substitute($table_name; “?[[bR]]”; “”). On the first attempt, it still failed. I went back in and found the next occurrence of the set variable, copied my script step to below that and ran it again. Lo and behold, the sync worked perfectly and has ever since. As I said at the beginning, this is a workaround and not a solution. The process is still adding the prefix, I’ve just figured out how to repair it. I still have no idea what the prefix means or how it got there. If anyone can shed any light on it, I’d be most appreciative. I’m just relieved that it’s over…for now. Marc

We've experienced some issues with corrupted documents in container fields which were included in the sync process. This affects PDF's and JPG's. This hasn't affected every record as far as we can tell. The files were inserted into the container fields in the main database on the server with external (Open) storage. They were transferred to the mobile device via a sync and were not modified on the mobile device, so should not have synced back to the main database. The corruption is in both the server and mobile files. I did read in another thread about an incompatiubility with the Compress option in the insert file dialog, but this seems unlikely as the end users aren't likely to have even noticed the option, let alone use it without first asking. I have no way of telling whether the corruption occurred or whether EasySync is the cause, but I really need advice as to the likelihood that it was and whether there is a solution. Urgent assistance would be most appreciated as we can't use the sync process for fear of potentially causing more damage. Thanks Marc

Finally got it working. Renaming the TO solved the problem. It took several days to do the initial sync though. Slow and unreliable internet and loads of data in the initial sync meant having to make several attempts. I ended up pre-loading the data and then syncing and it's now all good and shipped off to the client to download and install on their iPad's. Feeling very relieved. Thanks for the help guys. Marc

This may turn out to be premature, but I think I may have identified the cause of the problem and inadvertently fixed it. Thanks largely to the advice offered by GisMo, I turned on the push and pull debug options. As painful as it was dismissing four separate dialogs for every one of 1,284 records, it did prove where it was failing. The problem was with the main Projects table. It would have been the last one I would have switched off in my process of elimination. Whereas the dialogs for all the other tables showed the correct table name eg ES_TableName1, ES_TableName2 etc., the one for ES_Projects appeared in the dialog as ?[[bR]]ES_Projects. Here's where it gets a little weird. In the process of disabling all of the relationships except for ES_Projects and the one before it (which only had 24 records to sync), I deleted the table name ES_Projects and retyped it in exactly the same way. When I ran it again, the sync process worked perfectly. I can only assume that the TO name had somehow become corrupted. By re-typing the name in, it corrected it. I've now switched back on all 31 relationships and am in the process of running it. It will take several hours, so I'll report back on the final result tomorrow. Thanks for the advice. Marc

Let my rephrase my question. Is there any way I can get FM EasySync to show me the name of the table it's looking for when it generates the 106 error? Knowing that will greatly simplify my troubleshooting process (which has now lasted two weeks).

Error 103 is missing relationship.

We are so close to going live with this system, but we've struck a brick wall and need advice. First some background: The original system was built several years ago and has 50+ tables. Only 31 of those need to be synced to the mobile version of the file, which will be loaded onto iPad's to take into the field. Of those 31 tables, only half contain data which will be modified in the mobile version. The resat are mainly resource tables. We managed to get the sync process working perfectly on copies of the main file, but it refuses to sync to the actual file. It's extremely frustrating because the copy it will sync to, is an exact backup copy of the database. But, when I take a copy of the mobile file, change the external data source reference to the live file, it always returns an error 106. I have painstakingly checked every single one of the 31 relationships in both files at least 10 times and it still won't work. I even started switching off individual relationships in both files (renaming the TO's in the process) as part of a process of elimination, but each sync was taking several hours, before stopping with an error 106. I gave up after about five attempts and no success. I'm at a loss, my client is becoming angry at the delay and I can't think what else to try. Any and all advice is most welcome. Marc