Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About mdavis6537

  • Rank

Profile Information

  • Gender
    Not Telling

FileMaker Experience

  • Skill Level
  • FM Application
    15 Advanced

Platform Environment

  • OS Platform
  • OS Version

Recent Profile Visitors

2,456 profile views
  1. Thanks Sean. So if I don't have the server and hub records right now in the hosted mobile file, you would recommend creating them and just leaving all the fields blank except database version? And do I need to change the data base version in both the server and hub records?
  2. Hello, I am attempting to use this new feature in version 4 for deploying new versions of offline files. I want to make sure my hosted file that is being downloaded has the correct info in the mirror sync table. I have a seperate mobile file used by the iPads, seperate from the server file used for the desktop users. I am making my updates to the hosted mobile file. Questions: Since a single record is required in the mirrorsync table so as to put the new version number in field: "DatabaseVersion", should I have all other fields be blank in the mirror sync table?
  3. I noticed there were some improvements mentioned for MirrorSync 5 around password. I am currently using MirrorSync 4. With MirrorSync 5, are you now able to sync passwords to offline files? One of our biggest challenges is managing passwords for our offline iPad users, since if they forget their password, there is no way to reset it without re-downloading the whole file. Thanks.
  4. @Jesse Barnum Jesse I know this is an old post, has this changed in MirrorSync 3? I am using this and I seem to get a code 0 whether successful or unsuccessful on the sync. Just wanted to make sure it was still accurate. I am using Get(ScriptResult) Thanks.
  5. I was able to resolve this by checking the mirrorsync table for any records.
  6. Is there a variable I can check against to see if its an initial sync or not? Initial sync meaning the first time the user has done a sync with this file. Reason: MirrorSync is telling me it cant sync (the first time) because there is records in the database. I do have one record which is used in my update process from an old file to a new file. So I just want to delete that record before the first sync to resolve this error. Thanks. Edit - I guess I could just check for any records existing in the mirrorsync table, correct?
  7. Thanks for the replies. I follow what you are saying but currently I am doing my updates a bit differently using a blank (no records) file distributed to the users instead of having them download the hosted mobile file. We only keep 30 days worth of records on the iPad, so I am not sure its a huge deal if it has to go back and check all the records. Perhaps I need to change my approach but this is how I do updates today. I work on the updates to the new offline file for the iPads on my desktop. When its ready to deploy, I delete all the records in it so its completely blank. I sen
  8. Thanks Tsiry, Its seems this step is the one I am not doing: After the import, create a new record in the MirrorSync table on the hosted database. Set the type to 'Server'. Modify the sync4 field (you'll need to switch to layout mode to see which one that is), and set it to the timestamp when you ran the import, using the format 'YYYY-MM-DD hh:mm:ss' (in 24 hour time). Note: If you are not syncing with FileMaker Server (ex. MySQL<->FileMakerPro/Go) you will make this change in the offline file. However, that is going to prove difficult. The import into the offline
  9. Hello, I am using MirrorSync 3 with about 10 iPads. On the iPad solution, I have an update script that installs a new version of the file. As part of that process, all records are exported from the old file, and imported into the new file. What is happening is that after I release an update, MirrorSync on the iPad is deleting all the records and then inserting them all again after this update process is completed. I am assuming that something I am doing during the update process is confusing mirrorsync and it just decides to delete everything and re add it. Here is the process my up
  10. Great, thanks Jesse. I'll do some testing and hopefully it all works seamlessly. Thanks!
  11. Thanks Jesse. I assume the internal IDs are not the same as the Primary Keys in the database, right? (P.S. Is there any documentation that explains how all this process works? Would love to have a better understanding). One thing mentioned in the article is that you have to "show all records" for each table. I am wondering if that is going to screw up the order of the internal record IDs and cause issues. Do you have users using another update process? I am definitely open to suggestions.
  12. Hi All, In the process of rolling out our solution under the Filemaker SDK so it will appear more like a "native" iOS app. One of the things I want to include this time around is a way for our users to update the app. Currently looking at this process which basically adds another filemaker file, exports all the records from the old file to the new one, and then deletes the old file. My question is: If I use this process, what do I need to be aware of with MirrorSync to make sure that I dont run into any sync issues? All the timestamp data would be transferred. But I am not su
  13. I see in the patch notes in 2.6 that fixes were put in for duplicates. I am still struggling with issues with this, though i have had issues before this patch as well. I just had a new user get an ipad. Gave him the most recent copy of the file, downloaded using the MirrorSync client. Hit sync, it goes through successfully, and somehow managed to duplicate records for about the last 30 customers entered. I know this sync caused it because it was fine before and I looked immediately after syncing to see this (see picture). Whats worse is it seems somehow some child records are atta
  14. Great thanks- I will see if I can find it!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.