We discuss the general concepts relating to Servers and Databases in a chapter dedicated to them, so feel free to refer to it if necessary.

Database Explorer is a simple-looking form that lists all Servers and Databases you can access.

The form is split in two with a Splitter that allows you to adjust its layout to some extent.

In the upper portion of the form you find the Servers grid, and in the lower portion – the Databases grid. At the very bottom there's a Status bar with a little Clear button to clear, if you so desire, messages that may appear there once in a while.

Servers Grid.

The Servers grid lists the servers known to Alventis. Let's clarify something right away. Alventis can function in two modes:

What's important to realize is that Alventis can use both of the above modes concurrently, i.e., access some Databases locally, and communicate with remote Servers to access other Databases. Aside from the admittedly most important question "where is the data?", the rest is very similar no matter which access mode is in use. Which is why we will be referring to all data you can access locally as a "Local Server" – even though there is no server per se in this case.

Peer-to-Peer Shared Access. This is not a separate mode, but is nonetheless worth explaining in case you need it. As we have mentioned, Alventis can use Local mode to access data residing on another computer on the network. More than one user can access such data concurrently. Such Shared Access can provide multi-user operation for small groups of users that do not require the benefits of real Client-Server operation. Note that C/S mode is more robust since all data requests are "funneled" through a single Server application, presumably running on a secure, undisturbed, robust computer with adequate backup power protection, etc. And only C/S mode is truly multi-user in the sense of maintaining multiple user accounts, access rights and privileges, and so on.

Back to the Servers Grid now. Each line in the grid corresponds to a Server. Alventis will normally list at least one Local Server here, and in addition to that, you may add any number of Servers known to you. You would add a server by simply inserting a new record in the grid. Let's quickly go over its columns.

SrvID is just the order number of the Server record, it has no special meaning and no relation to the Server itself, so you can ignore this number for the most part.

Created and Modified are likewise, dates this record was created/modified (not the Server itself).

Name, Caption, and Comment are there mostly for your convenience: you can name the Server as you see fit, and leave yourself a comment if you wish: none of this is related to the Server itself, so enter whatever you want here.

Address. At long last we get to something that matters! If this is a record for a real remote Server (accessed in Client-Server mode), this is where you enter its address. C/S mode uses the TCP/IP protocol – same as used on the Internet, and the address of the Server must be specified the same way you'd specify the name of a Web server. It can be the name of the machine where the Server is running (e.g., "DepartmentHost" or some such) or its IP address (e.g., "192.168.0.1"). Either you know it already or your System Administrator should be able to tell you. Whoever is responsible for running the Server should know all the right values you may need to use.

If this record is for a Local Server (which is not a real server at all, remember?), the Address value is meaningless, so you can leave it empty or type "N/A" or whatever in there.

Type/Port/Service is another important column. It is this column's value that determines whether this record is for a Local or "real" Remote Server. It can be set to several things. When set to the word "Local", it indicates that this is a Local Server. You can type it or pick it from the combo box. When set to anything else, it means this is a Remote Server. "Anything else" can be any of the following:

Admin Port/Service. Technically, it's very similar to Type/Port/Service described above. Except that this is the TCP/IP Port/Service used for Administration of the Server. When left blank, it means "use default", which in this case is 12006. If you are lucky enough to be this Server's administrator, you must ensure you have the correct value here – to be able to administer the Server, that is. Just accessing data from the Server does not require a proper value here, so if you aren't the server's administrator, you can safely leave it blank. Same goes for the Local Server.

Remote Encryption Password. This column contains exactly what its name suggests for the Remote Server. The Local Server doesn't support this, so just leave it blank. Every "real" Remote Server encrypts its communications with you, at least to some extent. Server Administration is a subject of another chapter. Once again, this is a value your System Administrator should provide you with, but we'll let you in on a secret: the default value is "elevatesoft". This password is per-Server: each Server has its own single password of this type.

Full Encryption. When checked, it tells Alventis to encrypt all communications with the Remote Server, including all data transfers. When unchecked, the only part that will get encrypted is the authentication (when Alventis sends your Username/Password to the server). Alventis uses Blowfish encryption, in case you want to know. The Server may be set-up to enforce full encryption, in which case your attempt to relax the security will simply be ignored. In general, encryption obviously slows things down a bit, but if you need it, that's a small price to pay for security.

Compression. This column specifies the Remote Compression level for communications with the Remote Server. You may want to use more or less compression depending on the speed of your connection to the Server. A 100Mbps LAN connection is not likely to benefit from any compression, for example. A slower Internet connection may go faster with compression level set to 5 or 6 – around the middle of the slider scale. You may have to experiment a bit to achieve the best results. Or just use what we suggested in the above examples: 0 for LAN / 6 for slower.

UName. This is your Username that you use to log into this Server.

For a Local Server, it can be any valid user known to it. This is described in detail in the chapter on Administration. For now, you should be happy to learn that if there are any users known to your Local Server, they appear in the combo box in this cell, so all you have to do is pick one.

For a Remote Server, you have to know what your Username for this Server is and correctly type it in the cell. No combo boxes to help you here, sorry.

Available. This is mostly an indicator column. A checked value indicates that you are properly connected to the server. An unchecked value means the connection could not be established. You can attempt to re-establish a connection to a currently un-Available server by checking this checkbox. If Alventis succeeds, the checkbox will get checked. If not, it will remain unchecked, so you can try later.

Enable. A Local Server is always Enabled, so the checkbox is grayed-out and you can't uncheck it. A Remote Server can be Enabled or not. When Enabled, it simply tells Alventis that you do want to attempt to connect to this Server. When disabled, Alventis won't even try. This is useful if you have one or more Servers in your list, and these Servers may not always be accessible. Whenever you launch Alventis, it tries to establish a connection to all Servers listed here. If the Server is accessible, this is very fast. If the Server is not accessible though, it takes Alventis several seconds (around 5 – per-server) before it gives up and marks the Server not Available (in the preceding column). If you know in advance that one or more Servers in your list are currently inaccessible (or you don't want to even try accessing them for some other reason), you can speed things up by telling Alventis to not attempt to access these Servers in vain.

Any Server modifications you make here take effect as soon as you post the corresponding record. For example, if a Remote Server was previously not Accessible to you because you had specified a wrong Username or Password, as soon as you post your new Username to the Servers grid, you will likely get prompted for your Password.

Creating a Server record creates just that: a record in a list. Likewise, deleting a Server record merely deletes the corresponding record in the list. Neither of these operations do anything to the Server.

A word of warning. Alventis keeps track of Servers by their SrvID number. If you edit a Server's record (which means its SrvID remains the same) everything will be fine, as long as that record keeps referring to the same Remote Server. You can freely edit the Name/Caption/Comment (nobody cares at all), as well as anything else you like – as long as this record is still "pointing" to the same Server. If however you edit it in such a way that it starts referring to a different Server, Alventis will likely get quite confused by this with unpredictable results. Editing of Address and Type/Port/Service would likely fall into this dangerous category. If this is what you absolutely want to do, proceed with great caution and: close all forms that are referencing anything from the Server you are about to modify (except the Database Explorer form of course). Once this is done, perform the editing you want and post your changes. Preferably, decline the connection to the new Server if prompted. Restart Alventis. A "fresh start" should let Alventis get properly "re-acquainted" with the modified Server. But your safest bet is to simply create a new Server record and, optionally, delete the old one.

There are 3 buttons floating on top of the Servers grid. They all act upon the currently-selected Server.

Administration opens the same-name form for the selected Server. This is a subject of the chapter on Administration.

Change Password allows you to modify your password for the specified Username used on the selected Remote Server. Local Servers don't use any password-protection, so for them, this button is disabled.

Forget Password is rather similar. It makes Alventis (just your local copy) forget your Password, if it remembered it in the first place. Hopefully, clicking this button won't make you forget your Password. Because you will be prompted for it next time Alventis needs to establish a connection to this Server. Which is the whole idea. This simply allows you to enhance your security that was previously somewhat relaxed by the fact that your Password was stored somewhere on your computer. See the Authentication topic for a bit more info.

Databases Grid.

This grid lists the Databases of the Server currently selected in the Servers grid. Such being the case, all Databases listed at any given time belong to the same (you got it: currently selected) Server. Consequently, just as Servers, Databases can be either Local or Remote. The only difference between how they are listed is in the Location column. We'll go over all the other columns first though.

DBID is as usual, simply a unique numeric ID for the particular Database record.

Created/Modified are the usual dates for the record.

Name/Caption/Comment can all be set to whatever helps you identify the Database. You should set at least the Name, but preferably all of them.

Location is a bit more interesting. For a Local Database, it specifies the file system path where the data tables physically reside. It can be an absolute path like C:\SomePath\MyData or a path relative to Alventis' program directory: just MoreData would put the Database in the subdirectory MoreData under whatever directory Alventis is installed in. You can specify UNC paths too. Something like \\ComputerName\Path. Check your Windows Help if in doubt.

For a Remote Database, Location specifies the logical name of a Database on the Remote Server. This is described in the chapter on Administration. Luckily, whenever Alventis successfully makes a connection to a Remote Server, it automatically lists here all its Databases, so all Locations will be appropriately filled out for you.

Manipulating Databases. As far as Remote Databases go, this is neither the place nor time. No, really: this is not the form where you manipulate these, and it is described in the chapter on Administration.

Local Databases may be created and deleted right from the Databases grid. There's really very little to it. To create a new Database, you simply create a new record in the Databases grid. The most important part is properly specifying the Location, and we already told you what it should be set to. To help you properly pick a directory accessible from your computer, you can click the little dotted button in the Location column and browse to the directory you want. If you want to create a new directory, just type its path in the box, and it will get created for you. When you post your new record, if the directory you chose does not already contain a valid Alventis Database, a new blank one is created for you. If you picked a directory of an existing Database, you just established a "link" to it, but no new physical data got created. That is, you just let Alventis know about that Database so that it could access it, that's all.

Deleting a Local Database record is – as is often the case in Alventis – less destructive than you may initially think. It merely removes the record, so Alventis "forgets" about that Database. It does not delete any data in the Database. Feel free to delete it manually, outside Alventis, using your favorite file manager – if this is what you really want to do. Alventis won't have the "evil deed" on it conscience though. This is for your data's own protection.

Advanced and unsupported (i.e., "perform at your own risk") procedure: there's a useful consequence of what we have just explained. You can move a Database from one directory to another. The steps are: delete the Database in Alventis (the data remains intact); using your favorite file manager, move the data from its current location wherever you want; in the Database Explorer, create a new Database and point it to the new location of the data. An even more advanced unsupported procedure: you could move the Database from one directory to another without deleting/recreating the Database record. The procedure is quite similar: edit the Location to point to the new one; close Alventis; delete all newly-created data in the new location; move the data files from the old to the new location.

There are just a few more things you can do with Databases (regardless of whether they are Local or Remote) in this grid.

You can create a new UniGrid with the selected Database automatically added to it by simply double-clicking the Database you want.

You can add a Database to any currently visible UniGrid by dragging it onto the UniGrid's Tables Grid.

Finally, you can set a Default Database Style. Select the Database you want and apply a style to it like you would to a record in the Search Results. All tables of this Database (together with all their records) become painted with the style you chose. This is mostly helpful as a visual queue telling you at-a-glance the table or record's "origin".