|Home » Technical Support » ElevateDB Technical Support » Product Manuals » ElevateDB Version 2 SQL Manual » Getting Started » Architecture
|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.
|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.
|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.
|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.
|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.
|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.