Forms and Procedures not transferred reliably with new generations

Panorama X Beta 10.2
1

I have tested the transfer of updated forms and procedures by creating a new generation, and the changes are not reliably transferred to another client.

Computer 1 is running PanX Server.

Computer 2 is a (my computer) Mac mini (OS 10.15.4), PanX b6, patched.
I made a change to a shared database to a form and to a procedure.
I created a new generation and uploaded forms and procedures.

Computer 3 is an iMac (OS 10.14.6), PanX b6, patched.
I opened the shared database on this computer, and was prompted to update forms and procedures. I clicked Update Now.
The form was updated.
The procedure was NOT updated.
I chose Download Component, then procedures; It still did NOT update.
Close database.

I have repeated the new generation process many times, perhaps 20, usually choosing to upload forms or procedures, but not both. Sometimes the changes are transferred and sometimes not upon opening the second client. Sometimes I can follow up with downloading component, but sometimes it is grayed out even though the changes have not been made on the second client. The changes include additions and deletions of objects on a form, or addition and deletions of lines of code in existing forms. All of these are not reliably transferred to the other computer. Sometimes they were, sometimes they were not.

The notification on the second computer was 100% reliable in the notification that forms or procedures or both were out of date.

I have not tested the option of uploading everything even though it may be only forms and procedures that have changed, so I am not sure if that is always reliable or not.

2

Well that is discouraging news. I actually felt like this was one of the most thoroughly tested components of Panorama X Server.

3

An additional helpful data point would be to download the entire database from the server to Computer 3, using the Server Administrator wizard, then check to see if that contains the updated procedure. That would tell me whether the problem was in the procedure upload or download. If the problem is uploading, then even when downloading the entire database you will not see the changed procedure.

4

In the first test, computer 1 and 3 are in my former office; I connect to it via a VPN. The second computer is the one I am using.

I have done another test. One computer acts as a client and has the server running on it.
The second computer is on the same network.
I do not see any problem. The changes to forms and procedures are uploaded and downloaded without a problem.

The difference is that in the earlier test my computer is connecting to the office via a VPN connection. The server and the other client are in the office on the same subnet.

I cannot rule out the VPN connection as a source of problems, but it has been used by me for years with Pan6 and its server without a problem.

I may go to the office tomorrow and see what happens, which might show if the VPN is causing a problem.

5

I tested as you suggested.
I made a change to a procedure and to a form. Then uploaded the forms and procedures as a new generation.

The server is on a computer in my former office; I connect to that network with a VPN.

Then on a second client computer in the office (same network as the server), I opened the database, and chose update the procedures and forms. The form updated but the procedure did not.

Then I uploaded additional procedural changes as a new generation, then downloaded the database on the second client computer with the Administration Wizard (I used a link that generated on my computer because this client is logged in as a user and cannot access the administration wizard.) The procedure did NOT update.

Finally, I did a new generation with all fields forms and procedures. Then opened the database on the second computer and all procedures and forms were updated.

6

I would think it is very unlikely that the VPN is the source of the problem. If it was a problem, I would expect crashes and/or corrupted files. The VPN has no idea what data is transmitted and I cannot imagine that it could distinguished between bytes carrying forms and bytes carrying procedures.

Ok, in reviewing everything you wrote, it looks to me that in spite of the title of this post, you have not ever had a problem in transferring forms. Maybe I am reading too much into your exact words, so does this sound accurate – the forms have always transferred but the procedures have not?

If this is true, I have a theory. Here’s something you could do to test this. Before opening the Database Options dialog to upload a new generation, make sure you save the database. If my theory is correct, saving the database before uploading a new generation will fix the problem. My fingers are crossed, if this theory pans out the fix should be simple.

7

I have done five tests and made detailed notes.

In earlier testing, both forms and procedures have failed to sync.

What I think is that saving or not saving does not control the result. I saved the DB once before uploading, and syncing was successful. But I did not save in four tests and syncing was successful in one test and failed in three tests.

However following two failures of the second client to sync correctly, I then downloaded from the server using a link generated on the first computer. Result: successful both times.

From these tests, I think the failure is occurring on the download side.

What I did not test was whether making a New Generation with Field Arrangement and Data Types ever fails. That I do not know. I think that I will do that next, since that might provide a temporary work around to use until the forms/procedures issues is resolved.

I am emailing my notes in a PDF since I cannot upload them here.

PS I had not crashes all morning. I have done nothing to check any VPN issues; I have not gone to my office to see if there are any failures while on the same subnet as the server and not using a VPN.

Additional Testing:

I did three more tests. For these tests each time I chose a New Generation of Field Arrangement and Data Types. Test 1 was successful. Test 2 and Test 3 Failed.

After both failures, I used a link to download the database TimeClock, and then it was synced successfully both times.

In noticed that the download with a link function proceeds with the download even though TimeClock is open. The database does not appear to change, and I do not get any messages about where to save or replace an existing file. If I then close and reopen the TimeClock, the new version appears, and there is only one copy of TimeClock in the Finder. So it works even though the database is already open.

Further additional support to the hypothesis that it is the download process that is not working correctly. This does suggest a temporary work around: clients go through the update process, then do a database download with a link to ensure they have the up to date everything.

I see that the CL1 copy of the database is not saved automatically upon choosing new Generation Fields Arrangement… option, but it is save later when those change are actually uploaded. (I think this is always a two step process? No option just to proceed directly to upload that I see.)