In a perfect world, network connections will never drop, the power will never go out, and software will never crash. However, sometimes these types of disruptions do occur, and they can affect your database sharing experience.
Normal Client Server Operation
Before looking at disruptions, let’s review normal (non disrupted) interaction between a Panorama client and server. When a database is opened on a client computer, these steps happen.
- 1) The client contacts the server.
- 2) The server sets up a session for this client (if there isn’t one already). The server uses sessions to manage the connections with clients, each connected client has its own session on the server.
- 3) The server opens its copy of the database (if it is not already open). In other words, it loads the database into memory on the server.
- 4) The server determines whether there is any new data. If there is, that data is downloaded to the client.
- 5) The client merges the new data into its copy of the database (this is called synchronizing).
At this point, the connection between the client and server is considered established. To indicate this, the client shows a wifi icon in the tool bar (you can also make this icon appear in the body of a form, see setbannericon to learn how to do this).
As changes are made to the database, the client computer communicates with the server so that the server copy of the database gets updated (and eventually, other client computers are also updated through the synchronization process). Of course this communication requires that the network connection works, and that the server is still running. Later on this page we’ll discuss what happens if the network fails or the server software stops running.
Here are the steps that happen when a user closes a shared database:
- 1) The client contacts the server and tells it to close the database.
- 2) If no other clients are using the database, the server closes its copy of the database (removes it from memory). (Note: If the database is configured to load when the server launches, it will always stay in memory even if no clients are using it.)
- 3) If this client does not have any other shared databases open, the server will discard the session for that client. If the client later opens another shared database, a new session will be started.
- 4) The client closes the database (it is removed from memory, and all windows closed.
When everything is running smoothly, all these operations happen seamlessly and you don’t usually have to think about these steps at all. But if a disruption occurs, either the client and/or the server may be left in a problematic state. The rest of this page will explain how to diagnose and correct problems that occur if there is a disruption.
What if Panorama is Unable to Establish a Connection?
The previous section explained a five step process used to establish a connection with the server when a database opens. If there is a problem with any of these steps, the database will still open, but it will be offline (without a connection). When a shared database is offline, it can be viewed but it can’t be edited. This is indicated by a lock icon in the toolbar.
If you’re not sure what the problem is, you can click the icon and choose the Check Server Connection command from the popup menu (you can also choose this command from the File menu).
This command will attempt to contact the server and diagnose the problem. If the server doesn’t respond, you’ll see this message. If your internet connection is working, the server itself may have a problem - perhaps it needs to be restarted.
Perhaps the server is running fine but you had a temporary network problem that is now resolved. In that case, you’ll see a message like this:
Since the temporary problem is fixed, all you have to do is press the Connect to Server button and the database will be connected and ready to go.
If you have a complex multi-database application, chances are you often open multiple databases at a time. If the connection for one fails, they all will fail. However, you don’t have to reconnect them one at a time. When you use the Check Server Connection dialog, it will notice that there are multiple databases that failed to connect, and give you the option to connect all of them to the server in one fell swoop. (If for any reason you only want to connect the one you clicked on, you also have that option.)
What if the Connection is Disrupted While Working with a Database?
A disruption can happen at any time. Maybe your router needs to be rebooted, perhaps someone kicked out the power cord for the server computer. When that happens, Panorama will alert you to the problem. Depending on the option you’ve chosen in the Preferences>Client panel, you’ll either see an actual alert, or a notification. Either way, you’ll also see the sharing icon turn red.
If the cause of the problem was a network issue (for example a problem with your router), you can simply fix the issue and continue working. If you want to make sure you really fixed the network problem, click on the sharing icon and choose Check Server Connection from the popup menu (or from the File menu). If the problem is fixed, you’ll see a notification that the connection is verified, and you can then continue working with the database.
If however there is a problem with the server, the Check Server Connection command will display an alert. If the server can’t be contacted at all (for example if your network connection is still broken or if the server computer has lost power) you’ll be given the option to try again later or to take the database offline.
If you think you can fix the problem, you should press Try Again Later and then work on the fix. But if the problem seems to be permanent (for example you forgot to pay your ISP bill) you should press the Take Database Offline button. This will take the database offline immediately, without attempting to contact the server again. The database will show the pause icon, and you won’t be able to edit the data until the database is reconnected to the server (of course whatever problems that caused the disruption will have to be fixed first).
If the server is running but the database doesn’t have a valid connection, you’ll see a slightly different alert. For example this could happen if the server software quit and restarted (which shuts down the session the client was using). If this is the situation you’ll see a third option - Reconnect to Server.
If you press the Reconnect to Server button, Panorama will first take the database offline, and then immediately reconnect it to the server (remember, this option is only available if the Check Server Connection command is able to communicate with the server). So this button provides a quick way to get “back on the air” after a server reboot.
When you press the Reconnect to Server button, Panorama will check to see if there are other open databases that are also associated with the same server. If there are, you’ll be given a chance to reconnect all of them in one shot, rather than having to reconnect them one-by-one.
The reconnection process is basically the same as the normal process for opening a database – a session is started on the server, the database is opened on the server, and any recent changes are merged from the server to the local database. At that point you have a normal connection established, and you are ready to resume normal operation.
Continuously Monitoring the Server Connection
Panorama normally doesn’t attempt to monitor the server connection when you’re not performing any action. If the network connection drops and then reconnects while you’re just staring at the screen, you’ll never know. If you’d like to know, you can use the Preferences>Client panel to specify how often you’d like Panorama to monitor the connection.
If the monitor is set to 10 seconds as shown above, every 10 seconds Panorama will check the server connection for the active database (if the active database is single user, no check will be performed). If the connection is good, nothing happens. But if there is a disruption, the icon turns red (or a custom color, see below). There’s no alert or notification, simply a color change. If you want more information on the problem, click on the icon and choose the Check Server Connection command. As described in the previous section, this will display an alert with information about the problem, along with options for what to do next.
You may be tempted to set the period to a low value, even one second, so that you’ll immediately find out about any disruptions that occur. However, keep in mind that this will add a load to the server. If you have 30 clients and they are all monitoring every second, that’s 30 requests per second. In that situation your server might not have time to do anything else other than respond to monitoring requests, and regular data operations may be delayed. It’s generally a good idea to keep the monitoring period to 5 seconds, 10 seconds, or even longer.
Customizing the Error Icon Color
Since some users are color blind and literally can’t see red, the color displayed if there is an error can be customized. You can choose a color from the popup menu or type in any web color or RRGGBB hex web color, for example FF0000 for red.
See Also
- Automatic Record Numbering in a Shared Database -- generating unique numbers across multiple users.
- popupsharingmenu -- pops up a menu for the toolbar sharing icon.
- Record Locking and Editing Shared Data -- coordinating data entry across multiple simultaneous users.
- setbannericon -- sets the icon on the right side of the toolbar banner.
- Shared Database Synchronization -- data synchronization across multiple users.
- Sharing Icon & Context Menu -- operation of the sharing icon and pop-up menu (in the toolbar).
- Working With Summary Records in a Shared Database -- summary records are not shared between users.
History
| Version | Status | Notes |
| 10.2 | New | New in this version. |