We have one shared file that seems to refuse to sync with other computers accessing the shared file. One computer handles all of the data entry for that subject file. The only way that we can get the data to show up on other computers is for the other computers to Download Components and the check Field Arrangement, Data Types, and Data. This has become part of our workflow, but this is the first time that I have reported this strange file behavior. I am wondering if we have some setting wrong. Let me know if anybody has any suggestions or ideas.
Today I have worked a bit on trying to figure out why one of my client computers does not sync properly. I can add a record to a file on Client A. I see that the server has received the record in the same file. I sync the same file on Client B, but the record is not there. Each time I sync the file on Client B I get the notification “Already synchronized with sever.” However Client B has x number of records in the file while Client A and the server each have x+1 records in the same file. As anyone experience anything like this?
You may be wondering why we have discovered this so late in the beta testing process. We are still running our business on Pan6. Most of our PanX testing is on read-only files. We download each day fresh data from Pan6. Then we work away on PanX. We are now discovering that we are doing something wrong on PanX when we do add a record or make a change. Changes from Client A show up on the server. Change from Client B show up on the server. However when either Client A or Client B sync the file (using the Synchronize Data from the File menu) nothing changes on Client A or Client B.
One thing you could do to diagnose what is occurring is to use the logging features of PanX on the server. In case you don’t know how to enable the logging, do this:
On the copy of PanX on the server, start PanX, open Preferences/Logging, and select the events you want added to the log. Looks like this:
One Client A, find the server Id for the newly added recrord (use info(“serverrecordid”). Check the server log: is is there? Here is a line from the log showing of a newly added record with ID 5189. (The log is located in ~/Library/Application Support/PanoramaX/Server/Logs.)
09/01/2021 8:38:17 am Session 73 (Sandra ~ 2019 iMac:Sandra ~) added new record (id:5189 ts:10713) to database: TimeClock
Search the log to see if any other entries mention the server ID of interest.
Open the DB on client B: check the sync record from the server log; looks like this:
09/01/2021 8:38:11 am Session 73 (Sandra ~ 2019 iMac:Sandra ~) synchronized database: Timekeepers (ts:109-109 changed:0 deleted:0)
Now check if the record is present on client B. If you don’t find it, do a download data (option-Synchronize in the File menu). Now is the record present?
If the record is still not present, you should at least have a good idea of what went wrong.
Add a record on the client that you believe to be synching. Then open the client that you believe to not be synching. If the new record does not get added, then your non synching client is probably not using the most recent version of the shared database. I have had several time where I find that my non synching db has somehow gotten separated from the master. The only quick fix for this is to download a copy of the db on the non synching computer. Do the test again. If it works, then things are better. You may then have to merge old info from the non synched version into the newly downloaded file. When a file that is not properly linked to the server is opened, the present notices are not what they used to be and it is very easy to not recognize that you are not using a synching verson of the db.
Thank you for all of the suggestions. We may have solved the problem. The files are now working together properly. The simple solution was performing a Forced Sync (Option-Command-R) on each computer. I believe something strange did happen, but I cannot prove it. Before we performed the Forced Sync on all client computers, we downloaded from the server a new copy of the database to a client that refused to sync. Strange as it may seem, that did not solve the problem. Only after Force Syncing each computer were we able to get the syncing back on track.
That is very odd indeed, because what “force sync” does is simply a download.