Virtual Data Objects

Simple, fast database access

Download Purchase

Do you miss the simplicity of programming with ADO under Visual Basic 6? Are you tired of spending precious time creating and configuring ADO.NET DataAdapter, DataSet and Connection classes each time you make a change to your database? Is ADO.NETs disconnected model making your simple desktop application seem like a major enterprise programming task?

Infralution's Virtual Data Objects (VDO) may be the solution you have been waiting for. We give you back the simplicity and flexibility of the traditional ADODB programming model while allowing you to still take advantage of .NETs powerful data binding model.

VDO provides classes that wrap the standard ADODB Connection and Recordset classes allowing them to be used as fully featured data sources for .NET controls such DataGrid, ListBox, ComboBox and of course Infralutions own range of powerful controls.

It only takes two lines of code to populate a DataGrid like the one shown below - with no other design time configuration needed. If you decide to change your database schema there are no coding changes necessary!

DataGrid bound to VDO data source

Why use Virtual Data Objects?

Simplicity. For most desktop applications ADO.NETs disconnected programming model is just far too complex. VDO gives you back the simplicity of traditional ADO with out sacrificing the power of .NET data binding.

Performance. If your application involves browsing data from a large database then ADO.NET's in-memory model could be killing your performance and exploding your memory usage. VDO gives you lightning fast browsing on huge databases - particularly when coupled with Infralution's intelligent "Virtual" controls that only load the data necessary for the current display.

Price. At just $US 120 it isn't worth your while even thinking about home grown solutions. The time you would have spent reconfiguring Data Adapters and Data Sets each time you make a database change will cover the purchase price in next to no time.

What about ADO.NET?

With the advent of the .NET environment Microsoft introduced a new programming model, ADO.NET, to replace the previous COM programming model (Active Data Objects - now referred to as ADODB). ADO.NET was designed largely to meet the needs of large scale, distributed, web-oriented databases.

ADO.NET features a completely disconnected model in which data is loaded into an "in-memory" database (a DataSet). This model works well for the intended domain but has a number of short comings that make it awkward to use for traditional small scale, desktop applications.

Creating and managing ADO.NET classes is much more complex than ADODB. Typically you must create a Connection, configure Data Adapters, create a DataSet, set up Relations in the DataSet and the fill the DataSet with data. If you change the database schema you have to manually update the DataAdapters and DataSet. For small scale projects this overhead can completely outweigh any benefit the model might offer.

ADO.NET's in memory model means that it is difficult to build applications that allow an end user to efficiently browse a large database. ADO.NET puts the onus on the programmer to handle issues such as memory usage and paging of data.


Virtual Recordsets can be used as a data source for any .NET data bound control including DataGrid, ListBox, ComboBox and many third party controls .
See changes you make to recordsets automatically displayed in data bound controls.
Controls such as DataGrid and Infraluton's VirtualTree can automatically handle column sorting with no code required
Change the WhereClause for a VirtualRecordset and data bound controls will automatically update to display the filtered data.
Allow individual records within a recordset to be treated as independent objects (with minimal overhead) . This allows you to handle Virtual Records in the same way as any other standard .NET object.
Optionally create strongly typed records/recordsets - all the benefits of standard recordsets plus strong typing.
Traditional ADO connections limit the number of recordsets that can be open at one time. VDO's recordset caching mechanism allows you to open an unlimited number of VirtualRecordsets.
Full access to the underlying ADODB API including connection, recordset and field objects
Full support for standard ADODB Transactions
Full source code for Virtual Data Objects can be purchased separately allowing you to fully integrate the classes into your own application.