Panorama X Server Progress Report

That’s more or less how it works. In fact for changes to procedures, forms, and field options (like patterns or code), it is exactly how it works. The programmer can make and test these changes on his or her local machine, and no one else is affected. When the changes are ready, everyone else closes the database, you upload the new version to the server and then everyone reloads the revised version and continues on their way.

When you say “structure of the database” I think of things like inserting or deleting fields. That is a bit different, you have to lock everyone else out before you make a change like that. That is necessary, because if other users continued editing the data while you did that, there would be no way to apply their changes to your database (since the field structure is different), and their data changes would be permanently lost. So in that case, everyone else has to stop working while you change the database structure. But adding a field isn’t the kind of thing that needs much testing – you just do it and immediately upload, then everyone can resume work with the revised structure. If there are extensive coding changes that do need to be tested, you can do that as a separate new generation afterwards.

Jim, I wanted to add a suggestion to how shared databases might be changed in the future PanX server version. It will be fantastic if the programmer can make changes to his version of a database without disturbing other users on the system. Then when he decides to implement the changes, all other clients are locked into read-only while the new database changes are uploaded to the server. In my simple mind, you could take this one step further and allow the programmer to change the database structure after locking everybody else into read-only mode. I realize this would require some kind of tool to help the programmer keep track of fields and data, However, in theory the programmer could then, in a single step, upload the new database structure and download the latest data content saved at the time of the last lockout into read-only mode. Panorama would then be able to handle reasonable file structure changes without forcing clients into complete shutdown mode before structure changes are implemented.

If you think about it, this is not possible. The problem is the “download the latest data content” step. Once the data structure is changed, it is no longer possible to automatically synchronize changes made by other users that are still using the old structure.

It works for me too, what kind of error are you getting? I was watched it successfully. Upload a screenshot of your error.