Architecture

ElevateDB is an embedded SQL database engine that can be compiled directly into your application and offers local single and multi-user access (file-sharing) and client-server access with the provided ElevateDB server. ElevateDB can switch between these modes of operation quickly, requiring just a few application changes.

The following image illustrates the general architecture of ElevateDB:

The various areas of the architecture are detailed next.

Engine

The ElevateDB engine can act as either a client or a server:

Engine Type

Description

Client

When acting as a client, the ElevateDB engine can create and manage both local and remote sessions (see below). These sessions can be multi-threaded, and there is no set limit to the number of sessions that can be created. The engine is automatically started whenever a new session is connected.

Server

When acting as a server, the ElevateDB engine can also create and manage both local and remote sessions. More importantly, it can listen for and respond to incoming connections and requests from remote sessions. An ElevateDB server can listen for incoming connections on all IP addresses or a specific IP address. By default, the ElevateDB server listens for incoming connections on port 12010. The ElevateDB Server is multi-threaded and uses one thread per session connection. ElevateDB can cache threads and keep a pool of unused threads available in order to improve connect/disconnect times. You may have an ElevateDB Server (or several) accessing the same configuration file and databases at the same time as other local applications such as CGI or ISAPI web server applications. This allows you to put critical server-side processing on the server where it belongs without incurring a lot of unnecessary overhead that would be imposed by the transport protocol of the ElevateDB Server. This can improve the performance of server-based local applications significantly, especially when they reside on the same machine as the ElevateDB Server and the databases being accessed are local to the server machine.

Sessions

ElevateDB is session-based, where a session is equivalent to a virtual user. In multi-threaded applications ElevateDB requires a separate session for each thread performing database access.

A ElevateDB session can be either local or remote:

Session Type

Description

Local

A local session gains direct access to database tables via the operating system API to a given storage medium, which can literally be any such medium that is accessible from the operating system in use. This means that a local session on the Windows operating system could access database tables on a Windows or Linux file server. ElevateDB automatically provides for the sharing of database tables using a local session. For example, an application can use local sessions on a small peer-to-peer network to provide a low-cost, multi-user solution without the added expense of using the ElevateDB Server. A local session has all of the capabilities of a remote session. Before a local session can perform any operation, it must be logged in with a proper user name and password.

Remote

A remote session uses sockets to communicate to an ElevateDB Server over a network (or on the same physical machine) using the TCP/IP protocol. ElevateDB allows all remote session communications to be encrypted. Compression is also available for remote sessions and can be changed whenever it is deemed necessary in order to improve the data transfer speed. This is especially important with low-bandwidth connections like a dial-up Internet connection. A remote session connects to a given ElevateDB Server via an IP address or host name and a port or service name. Before a remote session can perform any operation on an ElevateDB Server, it must be logged in with a proper user name and password.

A developer can mix as many local and remote sessions in one application as needed, thus enabling a single application to access data from a local hard drive, a shared file server, or an ElevateDB Server. Also, local and remote sessions are completely identical from a usage standpoint, offering both navigational and SQL access methods.

A local ElevateDB session relies on a couple of important configuration items:

Item	Description

Configuration Path

This is the path where the configuration file is created and stored, and can be specified as being located in the process memory or on-disk. By default, the configuration file is called EDBConfig.EDBCfg, and is used by ElevateDB to store the information for the Configuration Database. ElevateDB can only access and use one configuration file per session, and the session cannot be connected when the configuration path is modified. Because the configuration file stores users, roles, and databases, among other things, it is very important that the configuration path is set properly for the local session, and that the local session uses the correct configuration file. Also, the configuration path is where all external modules are located, and it is where the system log (EDBConfig.EDBLog) is created and stored. ElevateDB creates a single hidden file called "EDBConfig.EDBLck" (by default) in the configuration path that is used for locking on the Configuration Database. It is created as needed and may be deleted if not in use by ElevateDB. However, if ElevateDB cannot write to this file it will treat the Configuration Database as read-only, thus preventing any modifications.

Temporary Tables Path

This is the path where ElevateDB creates any temporary tables used by the local session internally for SQL result sets, or for temporary tables created by the user via the CREATE TABLE statement. By default, ElevateDB uses the local user temporary files path in the operating system for this setting.

Please see your product-specific manual for more information on modifying the above configuration items.

Databases

ElevateDB stores all defined databases in the configuration file (see above). A database can be created using the CREATE DATABASE statement. The path specified when a database is created is subsequently used by ElevateDB to store both the catalog file and the database table files for the database. All metadata for a database is stored in the catalog file, and is represented in ElevateDB via the Information Schema. By default, the catalog file name for a database is EDBDatabase.EDBCat. Also, ElevateDB creates a single hidden file called "EDBDatabase.EDBLck" (by default) in the database path that is used for locking. It is created as needed and may be deleted if not in use by ElevateDB. However, if ElevateDB cannot write to this file it will treat the database as read-only. Please see the Locking and Concurrency topic for more information.

Tables

ElevateDB tables are divided into up to 4 physical files, one for the table rows, one for indexes, one for BLOBs (if there are BLOB columns present in the table), and one for published updates (if the table is published):

File Type

Description

Table Rows (.EDBTbl)	Used to store a fixed-length header for table-specific statistics along with the fixed-length rows. The use of a fixed-length header and rows allows for easier repair of tables in the case of physical table corruption. All rows contain a small row header and then the actual row data. BLOB columns contain a link to the BLOB file where the actual variable-length BLOB is stored in a block format.
Table Indexes (.EDBIdx)	Used to store a fixed-length header for index statistics along with the fixed-length index pages. The index page size is variable and can be set between 1024 bytes and 16 kilobytes on a per-table basis. All indexes defined for the table are stored in this file.
Table BLOBs (.EDBBlb)	Used to store a fixed-length header for BLOB statistics along with the fixed-length BLOB blocks. The BLOB block size is variable and can be set between 64 bytes and 64 kilobytes on a per-table basis. All BLOBs for all BLOB columns defined for the table are stored in this file.
Table Published Updates (.EDBPbl)	Used to store a fixed-length header for published updates statistics along with the fixed-length published updates blocks. The published updates block size is variable and can be set between 64 bytes and 64 kilobytes on a per-table basis.

The file extensions used for these physical files can be changed. Please see your product-specific manual for more information.

More Support Options

Support Forums

Frequently Asked Questions

Technical Bulletins

Technical Articles

Incident Reports

Roadmap