|Home » Technical Support » DBISAM Technical Support » Product Manuals » DBISAM Version 4 Manual for RAD Studio XE (Delphi) » Using DBISAM » DBISAM Architecture|
|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 Linux file server. DBISAM 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 client-server version of DBISAM. A local session has all of the capabilities of a remote session except for user and database security, which are only available from a database server. Also, with a local session a directory is synonymous with a database, whereas with a remote session databases are defined as part of the server configuration and the DBISAM client does not know the actual location of a given database.|
|Remote||A remote session uses sockets to communicate to a database server over a network (or on the same physical machine) using the TCP/IP protocol. DBISAM allows a remote session to be entirely encrypted using strong crypto. 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 database server via an IP address or host name and one of two different ports, depending upon whether the connection is a regular connection or an administrative connection. Before a remote session can perform any operation on a database server it must be logged in with a proper user ID and password. If a remote session is connecting to the administration port on a database server, the user ID specified during the login must be that of an administrator or the login will be rejected. Also, an administrative connection must be encrypted or the database server will reject the connection.|
|Data File||Used to store a fixed-length header for table-wide definitions such as the table description, field counts, autoinc values, etc., the fixed-length field definitions for the table, and the fixed-length data records themselves. The use of a fixed-length header, field definitions, and data records allows for easier verification and/or repair of tables in the case of physical table corruption. Please see the Verifying and Repairing Tables topic for more information. All data records contain a small record header and the field data. BLOB fields contains a link to the BLOB file where the actual variable-length BLOB data is stored in a blocked format.|
|Index File||Used to store a fixed-length header for index statistics, index counts, etc., the fixed-length index definitions, and the fixed-length index pages themselves. The index page size is variable and can be set between 1024 bytes and 16 kilobytes on a per-table basis. All index pages for all primary, secondary, and full text indexes are stored in this file.|
|BLOB File||Used to store a fixed-length header for BLOB statistics, etc. and the fixed-length BLOB blocks themselves. The BLOB block size is variable and can be set between 64 bytes and 64 kilobytes on a per-table basis. All BLOB blocks for all BLOB fields are stored in this file.|
|File Type||File Extension|
|File Type||Backup File Extension|
|File Type||Upgrade Backup File Extension|
|TDBISAMEngine||The TDBISAMEngine component encapsulates the DBISAM engine itself. A TDBISAMEngine component is created automatically when the application is started and can be referenced via the global Engine function in the dbisamtb unit (Delphi) and dbisamtb header file (C++). You can also drop a TDBISAMEngine component on a form or data-module to visually change its properties. However, only one instance of the TDBISAMEngine component can exist in a given application, and both the global Engine function and any TDBISAMEngine component on a form or data module point to the same instance of the component (singleton model). The TDBISAMEngine component can be configured so that it acts like a local or client engine (etClient) or a database server via the EngineType property. The engine can be started by setting the Active property to True.|
|TDBISAMSession||The TDBISAMSession component encapsulates a session in DBISAM. A default TDBISAMSession component is created automatically when the application is started and can be referenced via the global Session function in the dbisamtb unit (Delphi) and dbisamtb header file (C++). The TDBISAMSession component can be configured so that it acts like a local (stLocal) or a remote session (stRemote) via the SessionType property. A local session is single-tier in nature, meaning that all TDBISAMDatabase components connected to the session reference directories in a local or network file system via the Directory property and all TDBISAMTable or TDBISAMQuery components access the physical tables directly from these directories using operating system API calls. A remote session is two-tier in nature, meaning that all access is done through the remote session to a database server using the DBISAM messaging protocol over a TCP/IP connection. The database server is specified through the following properties:|
RemoteHost or RemoteAddress
RemotePort or RemoteService
In a remote session, all TDBISAMDatabase components reference databases that are defined on the database server via the RemoteDatabase property and all TDBISAMTable or TDBISAMQuery components access the physical tables through the DBISAM messaging protocol rather than directly accessing them.
You cannot activate remote sessions in an application whose TDBISAMEngine component is configured as a database server via the EngineType property.
A session can be started by setting the Active property to True or by calling the Open method. The TDBISAMSession component contains a SessionName property that is used to give a session a name within the application. All sessions must have a name before they can be started. The default TDBISAMSession component is called "Default". The TDBISAMDatabase, TDBISAMTable, and TDBISAMQuery components also have a SessionName property and these properties are used to specify which session these components belong to. Setting their SessionName property to "Default" or blank ("") indicates that they will use the default TDBISAMSession component. Please see the Starting Sessions topic for more information.
|TDBISAMDatabase||The TDBISAMDatabase component encapsulates a database in DBISAM. It is used as a container for a set of tables in a physical directory for local sessions or as a container for a set of tables in a database on a database server for remote sessions. Please see the Server Administration topic for more information on defining databases on a database server. A database can be opened by setting the Connected property to True or by calling the Open method. A TDBISAMDatabase component contains a DatabaseName property that is used to give a database a name within the application. All databases must have a name before they can be opened. The TDBISAMTable and TDBISAMQuery components also have a DatabaseName property and these properties are used to specify which database these components belong to. Please see the Opening Tables topic for more information.|
The TDBISAMDatabase Directory property indicates the physical location of the tables used by the TDBISAMTable and TDBISAMQuery components. If a TDBISAMDatabase component is being used with a local session (specified via the SessionName property), then its Directory property should be set to a valid physical path for the operating system in use.
The TDBISAMDatabase RemoteDatabase property indicates the name of a database defined on a database server. If a TDBISAMDatabase component is connected to a remote session (specified via the SessionName property), then its RemoteDatabase property should be set to a valid database for the database server that the session is connected to.
The TDBISAMDatabase component is used for transaction processing via the StartTransaction, Commit, and Rollback methods. Please see the Transactions topic for more information.
You can backup and restore databases via the Backup, BackupInfo, Restore methods. Please see the Backing Up and Restoring Databases topic for more information.
|TDBISAMTable||The TDBISAMTable component encapsulates a table cursor in DBISAM. It is used to search and update data within the physical table specified by the TableName property, as well as create the table or alter its structure. A table cursor can be opened by setting the Active property to True or by calling the Open method. The DatabaseName property specifies the database where the table resides. Please see the Opening Tables topic for more information.|
The TDBISAMTable component descends from the TDBISAMDBDataSet component, which descends from the TDBISAMDataSet component, which descends from the common TDataSet component that is the basis for all data access in Delphi and C++. None of these lower-level components should be used directly and are only for internal structuring purposes in the class hierarchy.
You can have multiple TDBISAMTable components using the same physical table. Each TDBISAMTable component maintains its own active index order, filter and range conditions, current record position, record count statistics, etc.
|TDBISAMQuery||The TDBISAMQuery component encapsulates a single SQL statement or multiple SQL statements in DBISAM. These SQL statements may or may not return a result set. It is used to search and update data within the physical tables specified by the SQL statement or statements in the SQL property. An SQL statement or statements can be executed by setting the Active property to True, by calling the Open method (for SQL statements that definitely return a result set), or by calling the ExecSQL method (for SQL statements that may or may not return a result set). The DatabaseName property specifies the database where the table or tables reside. Please see the Executing SQL Queries topic for more information.|
The TDBISAMQuery component descends from the TDBISAMDBDataSet component, which descends from the TDBISAMDataSet component, which descends from the common TDataSet component that is the basis for all data access in Delphi and C++. None of these lower-level components should be used directly and are only for internal structuring purposes in the class hierarchy.
You can have multiple TDBISAMQuery components using the same physical table. Each TDBISAMQuery component maintains its own result set filter and range conditions, current record position, record count statistics, etc.