ElevateDB for Visual Studio Database Developers
ElevateDB supports both navigational and SQL access methods. This means that you can:
- Directly Access Tables and Views You can directly access and update a table or view using the EDBCommandclass along with the EDBDataCursorclass's properties/methods such as ReadFirst, ReadNext, ReadPrevious, ReadLast, Locate, Filter, Insert, Update, and Delete.
- Execute SQL Statements, Stored Procedures, Scripts You can access and update tables using SQL, the EDBCommand class, and the EDBDataCursor class. Bothsensitive and insensitive result sets can be returned from any SELECT statement, and you can access and update any result set using the EDBDataCursor class's properties/methods such as ReadFirst, ReadNext, ReadPrevious, ReadLast, Locate, Filter, Insert, Update, and Delete. This gives you the best of both worlds, without sacrificing performance or functionality. ElevateDB is engineered to support both types of access, so you will not encounter performance issues when browsing large tables or selecting a single row for update with the EDBDataCursor class.
Click here for pricing and order information
|Database System Utility
||This utility allows the developer or end user to create, browse, update, restructure, search, query, and print DBISAM tables from a convenient and easy-to-use interface.
|Server Administration Utility
||This utility allows the developer or end user to administer a DBISAM database server from a convenient and easy-to-use interface. This utility can modify server configuration data, users, databases, and user rights as well as retrieve server log information. All functions are subject to having administrator rights on the database server being administered and access can be controlled on a per-user basis.
|BDE Database Transfer Utility
||This utility allows the developer or end user to transfer any BDE-accessible table(s) to DBISAM format with a few clicks of the mouse. BDE aliases as well as normal directories are supported as the source for transfers, making it easy to transfer an entire database with little or no effort.
DBISAM can be used as a single-user, multi-user, or client-server engine.
DBISAM does not pre-allocate large blocks of memory and uses, by default, a very small 128k of memory for each physical table in a session that contains BLOB fields and 96k for each physical table in a session that does not contain BLOB fields - 32k for records, 64k for indexes, and 32k for BLOBs (if present). These figures can be adjusted in the engine to allow for more memory consumption, if so desired. It uses a LRU cache management algorithm that also includes intelligent read-ahead buffering, optimized, serialized writes, and support for read-only devices like CD-ROMs with optimized buffering.
Automatic record locking and manual table locking is provided in DBISAM. Record locking can be configured to be pessmistic (default) or optimistic.
DBISAM offers transaction support in the form of buffered, serialized transactions that allow tables to survive unexpected client workstation power-downs with little, or in most cases, no data corruption. They are not, however, completely fail-safe.
DBISAM includes automatic change detection with a change detection policy that can be configured as "lazy" or "strict" on a per-session basis. This allows you to specify how current data should be when it is accessed by the application.
The in-memory tables in DBISAM are identical to disk-based tables and can be shared among multiple threads in the same application. You can create and use both local in-memory tables, which are stored in the client application's memory, or remote in-memory tables, which are stored in the database server's memory. In-memory tables can be used in SQL and can be mixed with disk-based tables.
Table Format Features
The default maximum file size in DBISAM is 4 gigabytes. You can enable extended support for files up to 128 gigabytes. However, this is only currently available for Windows only. DBISAM uses up to 3 physical files per logical table. All free space in DBISAM tables is automatically recycled. In addition, any free space can be removed from a table immediately by optimizing the table. DBISAM uses fixed-length record sizes and variable index page and BLOB block sizes. When creating or altering tables, some of the most useful feature include:
||The most common data types (including BCD, BLOB, GUID, and auto-increment) are supported in DBISAM tables, and complete and accurate NULL support is provided for all data types.
||Tables can be encrypted using strong encryption.
||Tables can be assigned a locale in order to control how sorting occurs in indexes as well as any searching or filtering done on the table via filters or SQL. However, currently this support is only available for Windows.
|Configurable index page and BLOB block sizes
||Both index pages and BLOB block sizes can be configured to optimize access and storage requirements.
||Tables can be assigned major and minor version numbers, which allows for easy structure version checking and updating.
|Long field names and field and table descriptions
||Field names can be quite long, and descriptions can be specified for tables and fields for reference purposes.
|Min, max, and required constraints, default values, and character-case specifiers for fields
||Simple expression constraints can be assigned to fields, and default values can be assigned automatically for NULL fields when records are added. Also, you can specify that a field be forced to upper or lower case whenever that field is modified.
||BLOB fields can be compressed to save space, and the compression is transparent once it is enabled.
|Primary and secondary indexes
||Tables can contain primary and secondary indexes that have case-insensitive, descending, and unique attributes, including mixed ascending/descending key fields.
|Configurable index key compression
||Index key compression can be enabled to greatly reduce the size of indexes and optimize access.
|Full text indexing
||Full text indexing is can be specified for any string or memo fields in a table along with stop words, space characters, and include characters to control how the indexing occurs.
DBISAM includes a subset of the SQL-92 standard, including a query optimizer, live and canned result sets, parameterized queries, scripts, and extended SQL syntax for DBISAM-specific features.
DBISAM includes support for remote client-server access to a DBISAM database server. You can switch between local or multi-user usage and client-server usage with just a simple change to a connection string. Remote sessions include support for keep-alive pinging or the ability to maintain sessions that can survive connection interruptions, complete with dead session management for sessions that will never be reconnected due to a fatal client problem. Connection timeouts for remote sessions can be adjusted, and an event is fired whenever DBISAM is about to disconnect a remote session due to inactivity.
Remote sessions can be configured to use compression and strong encryption when accessing a DBISAM database server.
DBISAM provides full local and remote administration capabilities. Databases can be backed up and restored manually or within scheduled events that automatically run at specified intervals. In fact, any administrative function can be run using a scheduled event.
DBISAM includes table creation and structure alteration, table verification and repair, table optimization, and import and export functionality. All of this functionality comes complete with progress, data conversion error, and log events to ensure that their execution can be customized and reported upon.