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.

What I said in July is still true, however, I just made a change that I think will be helpful for this situation. The video shows that in order to do a new sharing generation and change the structure of a file, all other users must close the database. That is no longer the case – now they can simply temporarily disconnect the database from the server. This means that they can still view the data while the structure is being changed, including searching, selecting, outlines, printing, etc. They just can’t modify the data while the new generation is in progress. When the new generation is complete, each user can reconnect, which will automatically trigger a download of the new generation to their computer.

This still requires other users to manually either close the database or disconnect before the new generation can proceed, but being able to disconnect without closing should make this process quite a bit less disruptive, as it no longer forces clients into “complete shutdown mode”, only a partial shutdown (no modifications). I’ve even already updated the documentation to reflect this change!

This is great news – about not having to force all users to quit PanX in order to change a shared file structure. Thank you for pressing forward on this issue. PanX Enterprise is going to be a World Class shared database.