I am losing data in my Shared files

Scenario: I look for my Wif-Fi icon and it is there. But attempting to update a record gives me a record can not locked because the session is not open (something similar.)

I check the server via Screen Sharing and yes, the server has again stopped. I restart serving in the Panorama Preferences Server pane.

I go back to the shared file and use the Disconnect from Server, then Connect to Server. It says all is good. But things are wiggy. I have a table (file) with 5 line items. If I have a record with 3 items filled in, I attempt to further update that record and add a 4th item. When I do that items 2 & 3 dissapear! I re-enter them. This happens on the next record as well. I figure I’ll close the file and re-open it to get things straight. After re-opening it and getting the Already Synchronized message, I try again. But it continues to empty previous line items when I attempt to add an additional line item to a record.
I have a field in the file that is a transaction of all entries in that file. I check the transaction field and sure enough, it does not show that I have entered anything in fields 2 & 3 in a prior session when in fact I am seeing data in fields 2 & 3 which causes me to try to enter data into field 4.
What I realize is that while I was previously working on the file adding data, I was actually off-line and all of my entering into those fields 2 & 3 was only local. But from my perspective, when I close the file, and re-open it, and get the Already Synchroized message, that I am working on a synched, correct file. But alas, any record that had been updated while offline, does show data in the fields, but it really is not there as far as the server is concerned. If I attempt to add to a later line item, the server locks the record, accepts the new data, and then empties the previous line item fields to synch the record in front of me with what the server knew about that record.

O my. So every record that I am looking at may or may not have good line item data. And I’ll only know when I attempt to make an additional change. Fortunately I have another source for what that 2nd & 3rd line items fields should be. But having data ‘look like it is there’ and it really is not is so not fun. And only being able to find which records have ghost data is not easy.

The only fix I can imagine is to delete the server copy, then figure out how to Force to Single User, and then re-upload to the server.

I have never used the server in a real multi-user mode as I’m wanting to wait until I find it better than Pan6. But I’m finding that using my files as a single user is safer than using them as a shared file. I was imagining that the shared file would give me a backup position if my local copy went wonky but in fact the shared situation is causing the issues.

My Enterprise server never quits. My Pano X Serve regularly quits serving.

In the very early days of using 10.2, I revised some forms used for entering data so that they do not have any fields linked to Text Editors. Instead, I used fileglobal variables, and put a Save and Cancel button on the form, and opened it as a dialog and made it non-closeable so the user could only press one of the buttons. The Save button triggered a procedure that saved the data from the form’s variables. It’s a lot of work, but it was completely stable once I had worked out all the little bugs (which I had inadvertently put in). It was a fair amount of work doing this.

Of course, this might not be a viable option for you, but something to consider.

BTW, are you running Cook’s Server Monitor on your server machine? If you are,
it would appear not to be working as intended, since it should check for a stopped server and restart it automatically.

And to offer another unsolicited comment, I would be sure to have the server logging turned on the Server machine, and I would check the log to look for clues as to why it has stopped. It gave me a sense of trying to solve the problem even though it didn’t usually yield the answer.

Unlike Panorama 6, there’s no special process needed for this in Panorama X. Just unclick the Share option.

Unfortunately, I do not have any perspective on what might be happening based on your description. As Tom mentioned, and as I have mentioned before, Panorama has extensive logging built in on both the client and server sides. Watching the logs is going to be the only way any actual progress is going to be made on problems like this. In several of the classes last spring I showed in detail what you should expect to see in the logs for any operation you perform on the server.

Since you are not actually using the multi-user capabilities, you might want to consider running the server on your computer, which would make it even easier to monitor the logs are you are working. If you enable the server icon in the dock that would also make it immediately apparent if the server is running or not. Since you are basically just testing at the moment, perhaps running the server on the same machine would be a good way to start, to see if you have the same problems, and if so, what the logs show.

It is my imagination that servers should not run on MacBook Pro computers that are constantly connecting and disconnecting from different networks, going to sleep, doing work without internet connection, restarting from other installations, etc. I am believing that a Panorama server is best on a stable computer with a static IP address that never gets restarted without a direct need for Panorama’s benefit. Thus I use a mini with a static IP for Panorama Server and nothing else. This has also allowed me to recognize that there is no other process or application that could be responsible for the issues I have with Panorama Server shutting down frequently and consistently with multiple minis being used through the years. As I’ve moved it from mini to mini, the problems are the same. Thus ruling out bad memory, surge issues, bad actors, meteor strikes, etc. Alongside that mini is another mini that runs Enterprise with a different static IP, sole use of the computer, and next to never stops serving. Once in a blue moon, some modal dialog will appear due to some OS issue.