Dimeric.Virtual.Database.

VDB is a database library for Delphi. VDB stands for virtual database, because it abstracts Delphi‘s numerous database libraries. VDB has several advantages: - Database Library Portability. You can easily switch between database libraries without even recompiling the program. This gives your applications the freedom to work with the Borland Database Engine, Microsoft‘s ADO, InterBase Express, DB/Express, or other third-party database libraries for Delphi. (See Connecting) - Simplified Coding. The VDB API is modeled primarily usi ng interfaces (IDatabase, IDataSet, IQuery, etc.). This means that VDB objects are managed, and resources are released automatically. In addition, while providing the familiar properties, methods and events of the built-in objects (TDatabase, TQuery, etc.) VDB provides additional simplified methods for performing common tasks. (See VDB Shortcuts) - SQL Dialect Abstraction. VDB provides abstraction for the underlying database SQL dialect. VDB provides an escape syntax so that you can write the same SQL regardless of the database you are connecting to. This escape syntax is automatically translated into appropriate code for the database‘s SQL dialect. For example, the macro for the database‘s current date and time would be CURRENT for the Informix dialect and getdate() for the SQL Server dialect. In VDB you would use the [now()] function. If you were connecting to Informix, this would be translated into CURRENT or getdate() for SQL Server. This makes code written to VDB more portable across SQL dialects. (See Vendor Neutral SQL) - Connection Pooling. If you set a few properties in a configuration string, VDB will pool database connections. This can significantly reduce the load an application places on the database. Application code simply acquires and releases database connections. Instead of being freed when released, however, connections are returned to a pool of available connections managed by VDB. When the application needs a connection, it is taken from the pool. The connection pool automatically grows and shrinks with demand. (See Connection Pooling) - Automatic Adaptive Query Preparing and Caching. If the same query is executed repeatedly, preparing the query ahead of time can reduce the overall execution time significantly. Because a prepared query is associated with a particular database connection, you normally don‘t use prepared queries as much when you use connection pooling (you don‘t leave queries prepared when you release a connection to the pool). VDB solves this problem by preparing and caching queries with the connection for a configurable timeout. VDB will adaptively determine when to prepare and cache queries. If the same SQL is executed multiple times within the timeout period, VDB will automatically prepare and cache the query. This means that you don‘t have to determine which queries should be prepared and which should not. VDB will do this automatically. This is especially useful when the pattern of code execution varies, as with library code or code that is executed heavily only at a particular time of day. ng interfaces (IDatabase, IDataSet, IQuery, etc.). This means that VDB objects are managed, and resources are released automatically. In addition, while providing the familiar properties, methods and events of the built-in objects (TDatabase, TQuery, etc.) VDB provides additional simplified methods for performing common tasks. (See VDB Shortcuts) - SQL Dialect Abstraction. VDB provides abstraction for the underlying database SQL dialect. VDB provides an escape syntax so that you can write the same SQL regardless of the database you are connecting to. This escape syntax is automatically translated into appropriate code for the database‘s SQL dialect. For example, the macro for the database‘s current date and time would be CURRENT for the Informix dialect and getdate() for the SQL Server dialect. In VDB you would use the [now()] function. If you were connecting to Informix, this would be translated into CURRENT or getdate() for SQL Server. This makes code written to VDB more portable across SQL dialects. (See Vendor Neutral SQL) - Connection Pooling. If you set a few properties in a configuration string, VDB will pool database connections. This can significantly reduce the load an application places on the database. Application code simply acquires and releases database connections. Instead of being freed when released, however, connections are returned to a pool of available connections managed by VDB. When the application needs a connection, it is taken from the pool. The connection pool automatically grows and shrinks with demand. (See Connection Pooling) - Automatic Adaptive Query Preparing and Caching. If the same query is executed repeatedly, preparing the query ahead of time can reduce the overall execution time significantly. Because a prepared query is associated with a particular database connection, you normally don‘t use prepared queries as much when you use connection pooling (you don‘t leave queries prepared when you release a connection to the pool). VDB solves this problem by preparing and caching queries with the connection for a configurable timeout. VDB will adaptively determine when to prepare and cache queries. If the same SQL is executed multiple times within the timeout period, VDB will automatically prepare and cache the query. This means that you don‘t have to determine which queries should be prepared and which should not. VDB will do this automatically. This is especially useful when the pattern of code execution varies, as with library code or code that is executed heavily only at a particular time of day.