Is there any way I can examine a server record (without screwing things up)? One user reported a syncing issue this morning.I confirmed that it did not sync to my copy this morning, but after doing a forcesynchronize, the record appeared. I wasn’t ready to report something, but plan to do some more testing. Along the way, I wondered is there a way for me to examine the server record?
Am I correct that server records have some kind of time stamp so the client and server can figure out what server records to download when the client copy of the DB is opened; is that right? ( I realize there is a lot I don’t know about what goes on here during the ordinary sync process.)
I don’t know if this can be reproduced, which is what I am going to try to do. (I used a second client and added a record; that synced to my computer when I opened the DB.)
Yes, this is described in detail in the section The Synchronization Process on this page.
This text is pretty much copied verbatim from the Panorama 6 Server documentation.
There’s not really any way to examine a server record. You can use the info(“serverrecordts”) function to find out what the “time stamp” of the current record is on the current computer, but there’s not really any way to find out what the time stamp of that record is on the server.
There is sort of a way. If you edit the record, or just lock with the lockrecord statement, that will download the record from the server to the client. So then you could use the info(“serverrecordts”) function to check the time stamp at that point.
By the way, forcesynchronize is probably a poor name. It should probably have the word “download” in the name, because that’s what it does – it downloads the entire database from the server. Synchronization is an attempt to be fast by only downloading what has actually changed. Forcesynchronize is just brute force “download everything, whether it has changed or not.” Ideally that should never be necessary.
Looking at the analytics I get, are you possibly finding Panorama X Server is working well enough to use in limited production? It looks like quite a bit of activity on your server, so perhaps you are. I would find that encouraging, I didn’t think it had progessed that far yet.
I am still working on the logging feature I told you about, which I am now calling Instrumentation. It’s turned into a bit of a monster project, I’ve spent almost 2 weeks on it now. It’s mostly done but I’m working on rather extensive documentation right now. As I document I find areas that need refining. Originally I thought this would just be a tool for me, but I think it’s turned into a tool that will be quite valuable for anyone creating significant apps in Panorama. So it’s an investment that should payoff for the life of Panorama. Our discussion of the Console app turned into more than a day of work, but I’m glad, because now I have this dialed in. Documenting how that works is my next project. (By the way, if the new instrumentation feature is turned on, the time stamps are recorded in the log.)
I would say no, it is not ready to use in limited production unless you have a small group and a lot of support. I have spent a lot of time, on a daily basis, dealing with issues. (Many of those are not server or Panorama issues, but procedures that I have written, either needing to be changed or having an error.) But there have been a lot of issues, most of which I have submitted to the forum. Here is a list of what I think are outstanding issues:
-
Updating databases through the server. In addition to the ‘failure to update’ issue that I identified and you are working on, I have twice had files so strangely altered that it had the wrong name on the file. In those cases, I deleted the database from the server and uploaded it again. But that resulted in problems with users. If they tried to update with this new file, it resulted in a very strange file. I haven’t reported more about that because I don’t have enough carefully documented detail to make it useful to you.
-
Assignment statement periodically causing a crash. I have reported this issue.
-
Failure to sync a record. I reported this yesterday and am trying to gather more detail for your consideration. This morning I confirmed a record on the server, which had synced to my computer, but was not on another computer. One of the databases, named TimeClock, is for hourly employees to enter their work hours, sick time, vacation, etc. I could see a duplicate entry for one person for today, which is not supposed to happen. The person whose initials are on the record does not have the record on her computer. (I haven’t checked her computer more carefully yet because she is working and I try to keep interruptions to a minimum.) She is a person who doesn’t tolerate well problems like this. I have used your timestamp trick to check the timestamp on records and I see they change when the record is modified.
-
Crashes. You saw my console list of crashes for a period yesterday; most of those were for the same issue (the assignment statement, which I crashed repeatedly in determining exactly where in the procedure it was happening). That one is particularly troubling because the procedure ran many times without a problem and them began failing every time. I was rarely experiencing crashes before beginning the server testing.
-
Problems downloading databases with the download links. There have been significant problems with this, but I wanted to try to document more carefully before reporting. Most of the testers are logged in as users, so I have to send them the download link to use with a browser in situations where the intended update is nor working. I am considering just emailing updated files to the beta testers as the update method.
Regarding our overall testing, I have five people using the server and PanX b6 (my shorthand for 10.2.0 b6 (3311) patched.). Everyone is working from home and connected to an office computer (use a software called Splashtop to make the office computer available, which seems to work well.). The remote use seems to work pretty well and I don’t see any issues related to that. But during corona-time the activity has been reduced a lot compared to pre-corona-time. In the new matters database, there have been 18 new matters opened. There have been 15 check requests by the beta testers. The time entry database gets the most entries, but even that is a pretty small number (50 entries.). So not a lot of activity, but that was my plan: to start small. One concern of mine is user acceptance. If there are too many problems, people get very impatient. I conducted training for everyone explaining that we are looking for problems so they can be fixed. But even so, if people are under work pressure, this can be irritating.
I have been using one very complicated database for two years with a single user. That was quite stable before the beta software, but a few problems have occurred since she installed the beta software. But I expect over time the problems, errors, bugs will be solved and life will return to problem free, at least as far as PanX databases. I have been working on PanX issues daily (mostly normal stuff and partly server related problems.)
I think I didn’t communicate well. From what you are describing, it sounds like you ARE using it for limited production. By that I mean with real data, for real work, however limited.
I agree with all of this. That’s why I didn’t think you were actually using this for production. But in spite of the problems, you are using it in production. So apparently even with the problems, it is usable enough to get limited work done.
At the moment, all plans for expanding the beta test program are on indefinite hold, pending resolution of the issues you are encountering. I’m concerned that these issues may be very difficult to track down and resolve, which is why I’m making a major investment in tooling right now to help diagnose these issue. I’m hopeful that you (or your associates) won’t decide to give up while I’m taking the time to do this. So the fact that you actually are getting some limited real work done, in spite of the frustrating problems, is what I meant by “encouraging,” a very limited sense of encouragement.
With you definition, I agree that we are using it for limited production.
With a lot of support, it is useable for limited production.
I do not expect to give up nor for the firm to give up supporting this effort. We could lose an individual, but that would be okay.
Hopefully soon it will all be going much smoother! In my experience beta testing is not a lot of fun for either the developer or the test participant. It’s the least favorite part of the process for me, but it can’t be skipped!