Procedure Code in a Shared Database vs. Panorama X Server

The relationship between procedure code on a client computer and Panorama X Server was not covered during the classes earlier this year. It didn’t occur to me to discuss this because there really is no relationship, but perhaps it will be helpful to some of you for me to elaborate on what no relationship means.

When you run a procedure on a client, that procedure runs only on the client. Your code never runs on the server. In fact, the server has no idea that a procedure is even running. Procedures are uploaded to the server as part of the database, but that is only so that they can be distributed to other clients. Your procedure code never runs on the server. (Note: I’m talking about shared database operation – if you are doing web publishing, your code will run on the server, but that is only in response to a web request, not in response to any action on a Panorama client.)

There are only a limited number of operations the server performs when working with data in a shared database. These 9 operations are the workhorses.

  • Starting a session.
  • Ending a session.
  • Opening a database.
  • Closing a database.
  • Downloading synchronization data to the client.
  • Locking a record.
  • Committing changes to a record (unlocking).
  • Adding a record.
  • Deleting a record.

There are also a few additional infrequent operations used when the client performs a change across multiple records, i.e. a fill or import operation, or for setting and accessing server variables. In total, there are 14 different operations that the client can request for the server to perform. A procedure running on a client cannot ask the server to do anything outside of these limited operations.

As you perform operations on a client database, Panorama determines which of these dozen operations must be performed by the server. Once a database is opened this is mostly locking, committing, adding and deleting. The server simply responds to this stream of requested operations. It has no idea what is going on on the client in any larger sense. It doesn’t know when a procedure starts, or when a procedure finishes, or when you are simply manually clicking and using menu items.

There are some additional operations performed on the server for maintenance, for example uploading a database or uploading and downloading a new database generation. But these operations cannot happen as part of your procedures, only thru the Database Options dialog and the Server Administration window. And it’s still only a limited set, about three dozen possible operations in total.

When you write a Panorama procedure, you currently have 840 possible statements you can use in your code, as well as 1014 different functions that could be used in formulas in the code and 29 operations. That’s a lot of possible variations – pretty much infinite. However, no matter what combination of statements and functions you use in your code, from the server’s point of view it will only see the 14 operations the server knows how to perform.

There’s a way you can verify this yourself. In the Preferences window, go to the Logging panel and enable all the Sharing options:


If you look at the log, you’ll see that no matter what operations you perform on the client, you’ll only see a limited number of operations happening on the server. This is a topic that I did cover during the server Deep Dive sessions, so I would recommend reviewing those if you are interested in the exact details.

1 Like

That is very valuable to know as that means there are very few things to investigate to figure out why when I run a procedure on my client, the server crashes.

I guess I would first look at the FormulaFill as each of the procedures that crash the server have that command.

Excellent - now we’re getting somewhere. See my further response on your original thread for more ideas.