Enterprise Design/Architecture


I am thinking about re-architecting a set of Enterprise databases I use.


Currently, there are three databases that are shared databases and that interact with each other.

These databases each have Forms and Procedures in them to interface with their specific data.

Whenever any of these Forms or Procedures are updated or modified in any way, there are several steps in the workflow to update these databases both on the server and ensure all the clients/users get the updates.

Additionally, once these changes have been made, all users must update their databases in order to continue accessing the data and all users then get the new UI components, regardless of whether they want or even need those changes.


So, I was thinking of re-architecting the whole system by, essentially, separating out the “UI components” from the actual data.

In essence, I’d move all the “UI components” (Forms/Procedures) out of each of the shared databases into one (or more?) non-shared databases.

These non-shared databases would load the shared databases as “secret” databases and pull data, as needed, from those databases.

I am hoping this kind of separation would allow for easier, and selective, updates of the UI without requiring all users to update at the same time.

The only “global” updates that would be required would occur if/when the actual data structure (fields add/removed) of the data is modified.


  1. Has anyone done this kind of approach?
  2. If so, what your experiences and “pros” and “cons” that you’ve discovered with this kind of approach?


– Mark

You can already do this simply by not updating the server when you modify forms and procedures. You can simply manually transfer the files to whatever users need the changed files.

The only time you have to update the server, creating a new sharing generation, is if you need to add, remove or change the type of any fields in the database. But you don’t have to create a new sharing generation for changes to forms or procedures.

If you don’t update the server after changing a form or procedure, Panorama won’t automatically force all clients to update the next time they open the file. So distributing changed databases with new forms or procedures will have to be done manually, perhaps using DropBox or Airdrop, or even email. But that would have to be done manually for the scheme you are proposing also.

Hi Jim,

If I had thought a bit more, I would have realized that, too.
Eventually. :roll_eyes::smiley:

Thanks for the comments!

– Mark