This chapter is only relevant to Remote Servers. Local Server doesn't have any settings we are going to discuss here.

Aside from Database maintenance, if you insist, which for the Local Server is performed directly in the Database Explorer form.

Server Administration is performed in the 4 last tab sheets of the Administration form. The first 3 tab sheets are dedicated to Alventis Security and have been dealt with in the Security and Administration chapter.

The Databases tab sheet is remarkably simple.

Name is the name of the Remote Database. This is what appears in the Location column in the Databases grid of the Database Explorer form for Remote Databases. You can't change it for an existing Database.

Path is the physical file system path to the directory on the Server where the Database's data tables are located. This path is specified relative to the Server application. That is, it is the Server that will be resolving it from its "point of view". Let's illustrate this with an example. Imagine we have the Server running on a computer called Alpha, which has (or will end up having) a Database in the directory C:\ServerData. Imagine that were are administering this Server from Alventis running on another computer called Theta. Imagine finally that Theta has direct access to Alpha's hard disk C: - either via a mapped drive letter R: or using a UNC path. You may be tempted to enter the path to the Database directory as you may see it from Theta: either as R:\ServerData or as \\Alpha\C$\ServerData. The latter may even work, but you shouldn't use it, and the former certainly won't work at all. The path that should be entered is C:\ServerData – because this is what the Server running on Alpha sees and understands.

To further confuse you, there's a little dotted button in the Path cell that helps you browse to a directory. It will work great if you are administering a Server running on the same machine you are administering it from since in this case both Alventis and the Server are sharing a common "point of view" of the file system. If administering a Server on a remote machine though, you must use this button with great caution. Even if you do manage to browse to the remote directory you want, once you have done so you must edit the beginning of the path to make it "understandable" to the Server (as in the example above where we replaced the beginning by "C:").

Any modifications enable the Save Databases button. As with other similar buttons in this form, you must remember to save your changes before closing the form (it won't remind you).

The Re-read Databases button abandons your changes, if any, and updates the list with whatever databases currently exist on the Server.

Editing the Path of an existing Database will not move any existing data to the new location. It will create a new blank database there and abandon the old.

Deleting a Database does not delete any data tables either. It merely removes the Database in question from the Server's internal list of Databases known to it.

If you do need to "move" your Database, you may want to simply copy its entire data directory to the new destination (using your favorite file manager – and in all likelihood when the Server is shut down and nobody is connected to the Database), and only then change the Path in the Databases grid. Once this is done, you can remove the original directory at your leisure.

The Settings tab sheet is depicted below.

We have already been through the Levels and Table Protection groups of controls on the right in the chapter on Security, so we will only describe here the controls we find on the left.

Server Configuration group contains everything related to the Server's setup that can be configured remotely.

Max Connections specifies the maximum number of concurrent connection the Server may accept. The default value is 100. The maximum possible value is 32,765. You may want to set this value to some low number if you want to limit the number of concurrent connections for performance or other reasons.

Connection Timeout specifies for how many seconds a Session may remain Idle before the Server automatically disconnects it. Default: 300.

Dead Session Cleanup Interval specifies, in seconds, how often the Server checks for expired Dead Sessions. Default: 30.

Dead Session Expiration specifies after how many seconds a disconnected Session is considered Dead. A value of zero (0) indicates that Sessions are never considered Dead. Default: 43200 (12 hours).

Max Number of Dead Sessions specifies how many Dead Sessions the Server will keep around before it starts removing them in the oldest-first order. Default: 64.

There's little reason for you to care about it, but let us briefly tell you in case you do. Alventis communicates with a Server using what is known as a Session. A Session is established when Alventis makes its first request to the Server, and may persist indefinitely – depending on Alventis' activity. While Alventis is actively communicating with the Server, the corresponding Session is active. As soon as Alventis makes a pause, the Session becomes Idle. If the Session remains Idle for a period that exceeds the Connection Timeout value, the Session is disconnected. If after that the Dead Session Expiration time interval passes (if it is non-zero), the Session is considered Dead. The Server periodically removes Dead Sessions – once every Dead Session Cleanup Interval seconds. If Dead Session Expiration timeout is set to zero, disconnected Sessions do not become Dead, but the Server simply removes them when their number reaches Max Number of Dead Sessions.

You are not likely to ever need to modify the above settings.

The Addresses Allowed list box is where you can specify Allowed IP addresses. Default: "*", i.e., "everybody".

The Addresses Blocked list box lists IP addresses from which the Server will not accept any connections. Default: empty list.

The IP addresses can be specified explicitly or using the asterisk wildcard, e.g., "192.168.5.*".

Be careful to not deny yourself access to the Server!

Server Temporary Directory is the directory, on the Server's machine, where it stores any temporary files. It defaults to the Server's %TEMP% directory. This directory must be specified from the Server's "point of view" just like the Path of a Remote Database – see the discussion pertaining to that.

The Deny New Connections checkbox, if checked, will make the Server not accept any new connections.

The Reload Saved button abandons your changes, if any, and reloads the current configuration from the Server.

The Save Settings button updates the Server's configuration.

The Credentials Caching group of controls specifies how lazy this Server's users are allowed to get.

Username may be cached by clients, when checked, means that if a user wishes to do so, he can let his copy of Alventis (his "client" software) remember his Username. To do so, he'd check the corresponding checkbox in the Authentication dialog.

Password may be cached by clients does the same exact thing – but for the user's Password.

Enabling both checkboxes relaxes your security a bit since now each user's local copy of Alventis will have his credentials stored somewhere (even though a user is not likely to be able to read them).

You can disable Username and/or Password caching at any time. The only issue you should be aware of is that Alventis will still use the cached credentials (if it has already cached them in the past) at the time of the next login. At that point, Alventis will diligently "forget" the cached value to comply with the new Server policy, so subsequent logins will require the user to enter his credentials by hand.

The Sessions tab sheet may look busy, but it mostly presents read-only status information.

At the very top we find some Server status information boxes: Server Name and Version, as well as Memory used by the Server application and its Uptime.

At the bottom there are a few TCP/IP settings: the Data Address and Port pair and the same for the Administrative access.

The chapter on the Server Installation explains how these are set.

The middle of the tab sheet is occupied by a list of Sessions that currently exist on the Server.

User shows the Username this Session belongs to.

Address will display the IP address the Session is connected from. If the Session is Dead (i.e., it has been Idle long enough), this column will change to "Was " followed by the last-known IP address.

Created is the time the Session got created.

Last connect is the last time the Session (re)established a connection.

Encrypted tells us if the Session used full data encryption, which would be the case if the user enabled the Full Encryption checkbox for this Server.

To the right of the Session list, two status boxes display the Total number of Sessions and how many of these are currently Connected.

The Disconnect button just below allows you to manually disconnect the selected Session. To be perfectly honest, we can't think of any reason for you to do so.

In the top/right corner there's a Refresh button that allows you to manually refresh all the info displayed by this tab sheet. You can force it to auto-refresh every 15 seconds by checking the checkbox under the button.

Lurking in the bottom/right corner is the Stop Server button. It allows you to stop (and restart) the current Server. Stopping the Server will close all active connections, which may lead to users losing their work if they are in the middle of an unposted editing operation, so be very careful.

The Event Log tab sheet displays the current event log of the Server. It uses the following format: Date/Time, Event Type (which could be: Infrm/Warng/Error which stands for Information/Warning/Error respectively), some Client information in brackets: Version, Address, Username (if available), Session ID, Request, and whether it was Encrypted, and all this is followed by the Status Message, e.g., "Connection accepted".

The Refresh button at the bottom re-reads the log from the Server.