Jump to content

Zach360Works

360Works
  • Content count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Zach360Works

  • Rank
    newbie

Profile Information

  • Gender
    Female
  1. Reading the MirrorSync AuditLog

    Hello Reliant_Reed, As far as documentation to read the Audit Log, there is none. Was the modification timestamp altered during the sync? That could be one way to determine if there was a change made to the record. If you would like to view the MirrorSync logs themselves then go to the location C:\Program Files\360Works\Applications\logs for windows or /Library/360Works/Applications/logs for Mac and find the MirrorSync log for the date in question. If the primary key is unique, like a UUID, then you will be able to run a search for that value and look for logs that indicate changes in the record. If you have any trouble with this please feel free to go to the MirrorSync homepage (The same webpage where you originally launched the configuration client) and submit a problem report. We would be happy to assist you further then. - Zach Lee, 360Works Support Team
  2. Hey Woz, Would you be available sometime this week for a screen sharing session? We are interested in this as well and would like to see what is going on. Best, Zach Lee 360Works Support Team
  3. Version 4 automatic script

    Hey Mazkot, Here is the recommended way to do this: In the script that the sync button is linked to - you add a call to the script that you would like to run before any of the script steps already listed. In this script you can check for a field in the MirrorSync table listed as LastClientToken. If this field is empty then it means that it is your clients first sync which could indicate that they need to run your script. Also run a check for the DavabaseVersionNumber in the mirror sync table. If this number is different than what you are already running then they should run your script. -Zach
  4. Hey Ron, From the advanced documentation on MirrorSync managed keys: --- A very different approach is to allow conflicting primary keys to exist on each separate database, without ever writing those primary keys to other databases. When record #11 is written from the first database to the second (in our original example), instead of being written with primary key 11, it is written with primary 51 (the next number in the sequence on the second database). This has the advantage of the shortest possible primary keys, which are pure numeric values, with no possibility of conflicts. It is also the way that the majority of existing databases are designed. MirrorSync supports this method (and is the only sync framework that does, to our knowledge). It creates an internal table to translate between the primary keys on all database that are syncing, so that when record #11 is later updated, MirrorSync knows to change record #51 in the second database. MirrorSync also re-writes foreign keys when they are written from one database to another, so that foreign keys that contained '11' on the first database will be re-written with '51' in the second database. --- This is a brief overview on how MirrorSync managed keys will work. If MirrorSync is configured correctly, the corresponding foreign key fields that match with the primary keys will be also changed when the sync is performed. MirrorSync stores data from each sync allowing it to remember exactly which record it matches with on the hub database. If you are only syncing with one device and not using any filtering then there is no need for this feature. If you are syncing with more than one device and, for example, you are offline adding your own patients while others get added at your home office, this feature becomes useful. Lets say in the time that you are offline, your home office adds 10 new patients and syncs with your hub database. The hub database now has records with serial numbers 1 - 10. Now in Hati you add 2 new patients, a father and son. The son has a serial number 1 and father 2. The son's foreign key field that references his father's serial number is set to his (the father's) primary key: 2. If that relationship is set up and configured correctly this is what will happen: When you are back online and begin your sync, MirrorSync will recognize that none of the new records that you created while offline existed during the last time you synced with the home database. Since the home database now has records that are numbered 1 - 10, MirrorSync will begin adding the new records from your phone to the hub as 11 and 12. Also, since your foreign key fields are configured to be related to primary keys using a self join relationship, these values will also change. So in your home database you will now have 12 records, the sons serial number will be 11 and the fathers will be 12. Also since the father's serial number has changed to 12, mirror sync will ensure that the sons foreign key field referencing his father's primary key is also changed to match. I hope I gave you some answers that you were looking for, if I'm not understanding your question or you would like to know more please let me know! Thanks, Zach
×

Important Information

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