Home Products VistaDB 2.1 Embedded Engine

2.1 is no longer sold or supported - these pages are for reference purposes only. VistaDB 3.x should be used for all new development.

VistaDB 2.1 Embedded Engine

The VistaDB 2.1 unmanaged engine is included in each VistaDB product. The VistaDB products each have VistaDB components that allow software developers using Delphi, Visual Basic and VBScript to build database applications for Win32 and ASP using SQL-92 commands or VistaDB's own high-speed Direct Data Access™ data objects.

The VistaDB embedded SQL database engine is responsible for processing SQL commands and for performing the low-level reading and writing of data in a VistaDB .VDB database. The entire engine is contained in a single 500KB .DLL file called VistaDB20.DLL which may be freely deployed with your applications. The engine .DLL does not require any special registration or configuration on the end-user machine. It can be placed in the same directory as your applications or it can be copied to the C:\Windows\System32 directory to be shared by all of your VistaDB applications.

Engine Features

• Small 500KB footprint
• Robust single-user and multi-user support
• Fully multi-threaded compatible
• Row level and table level locking
• Royalty free unlimited distribution
• High-speed SQL-92 query processor
• Snapshot isolation level Transaction Processing supports unlimited nested transactions
• SureCommit™ fault-tolerant data maangement
• Direct high-speed, low-level data reading and writing
• In-memory databases and tables

Single-User and Mult-User Support

Applications built using VistaDB 2.1 can access data on local drives and on shared network drives (e.g. F:\MyDatabase.VDB) in both single and multi-user mode. That means multiple users can access the same database and tables concurrent .This type of multi-user data access is often referred to as a "file server" or "peer-to-peer" configuration.

Developers benefit from VistaDB's table and row locking so that applications can lock rows for editing, or lock tables for general file maintenance. The built-in Snapshot Isolation level Transaction Processing helps ensure good data integrity. Developers using VistaDB's DDA technology can manage table and row locks manually. Either way, data can be simultaneously accessed by multiple users.

In a shared network scenario, Windows workstations require additional resources to manage the sharing of the database file, or any file for that matter. Each VistaDB client application running on each Windows workstation must open the entire .VDB3 database file on the shared network drive, which can cause network traffic. This is because the Windows file sharing sub-system is in control of how the file (i.e. database) is open.

The key point to understand is that the first user that accesses the VistaDB database on the shared drive will experience very good performance relative to local desktop access. Windows recognizes that he is the only user of this file and so Windows is able to open the database in a type of exclusive mode (The VistaDB open mode settings have no affect on this Windows setting. This is internal to Windows). However, the moment a second user accesses the same database, Windows drops its exclusive mode file access down to a shared mode file access which is magnitudes slower.

Even after the 2nd user closes his connection to the database, and the first user is back to being the only user working on the database, this first users's Windows workstation does not resume exclusive mode file access until the file (i.e. database) is closed and re-opened. The solution is to not keep connections open in this type of environment or to use the VistaDB 2.1 Server

User Defined Functions (UDF)

VistaDB allows you to create custom user-defined functions that extend the built-in V-Script functions provided by VistaDB. Developers can use Delphi to quickly and easily create these powerful UDFs which are Win32 .DLL files that contain exported functions. UDFs are recognized by the VistaDB20.DLL engine as native functions. UDFs can be used to define powerful Triggers and V-Script indexes.

For example, if you want to dynamically split a column called "FullName" into "FirstName" and "LastName" indexe keys, you could create 2 UDFs: ExtractFirstName( [fullname]) and ExtractLastName( [fullname] ) that will return the extracted text. ExtractFirstName would contain logic that returned the first part of the "FullName" column and ExtractLastName would have logic that returned the second part of the FullName data. The returned value would then be processed by the VistaDB engine as if it came from a native function.

Steps to create a UDF

1. Create a UDF Win32 DLL using Delphi that contains some exported functions
2. Create a VistaDB20.UDF text file that tells the VistaDB20 engine where the UDF .DLL is, what funtcions are available and how to call them
3. Copy the .UDF into the same directory as the VistaDB20.DLL

VistaDB20.UDF is a text file that contains a list of all UDF functions with corresponding DLL names and functions. This VistaDB20.UDF file must exist in the same directory as the VistaDB20.DLL engine. VistaDB allows you to define an unlimited number UDFs. Each UDF supports up to 8 parameters. UDF parameters and the return value can be one of the following types:

• CHARACTER
• BOOLEAN
• INT32
• DOUBLE

The UDF file variablss are as follows:

• DLLName - full path and name of the .DLL that contains the
• UDF DLLFuncName - name of exported function in the .DLL
• vFuncName - alias name of the DLLFuncName that is recognized by V-Script
• ReturnType - return value type (one of the types listed above)
• Param?Type - 1 of 8 param types (e.g. Param1Type) (one of the types listed above)